Binary distributions of 0.4.3 for Windows on pypi.python.org are broken

[grzn]

Here's the exception we get after installing greenlet==0.4.3 in Python 2.7 on Windows:

 File "C:\Jenkins\workspace\logging\tests\test_timing.py", line 1, in <module>
    import gevent
  File "c:\jenkins\workspace\logging\eggs\gevent-1.0.1-py2.7-win-amd64.egg\gevent\__init__.py", line 36, in <module>
    from gevent.hub import get_hub, iwait, wait
  File "c:\jenkins\workspace\logging\eggs\gevent-1.0.1-py2.7-win-amd64.egg\gevent\hub.py", line 8, in <module>
    import greenlet  # http://pypi.python.org/pypi/greenlet/
ImportError: DLL load failed: The specified module could not be found

The pyd file exists next to the init script, so I'm guessing there's a problem with building the extension?
When we build and install from source (on machines with VS2008) the import succeeds.
We get the same results when installing from the wininst distribution, or the egg distribution.

Version 0.4.2 works, so I'm guessing you changed something in the build process?

[snaury]

Yes, as a new maintainer I don't (and don't plan to) have Visual Studio 2008 Professional, and my copy of Visual Studio 2008 Express doesn't have any x64 compilers. When building I used Windows SDK, which uses Visual Studio 2010 for amd64, and Python picked that up. The built library seems to work without problems, but of course it requires the runtime to be installed, which can be downloaded here: http://www.microsoft.com/en-in/download/details.aspx?id=14632. Usually it's already installed since it's often needed by a lot of software, but a relatively clean system would be a problem.

The only alternative would be not to provide 64-bit binaries for Python 2.x, but I think it would cause more problems for users that don't use Visual Studio at all.

[grzn]

All the builds until now were done with 2008, and 0.4.3 doesn't work for them.
Also, Python2 is compiled with 2008, and people are used to having the 2008 runtime, and it makes sense to build the binary distributions with the same compiler as Python was compiled with.

You're right that Python moved to VS2010, but only with Python3.
We can help with building the packages for Python2 in our internal CI, if you're interested.

[snaury]

@grzn by "doesn't work for them" do you mean it cannot be imported due to runtime or is there something else wrong with the compiled library? Since greenlet doesn't use files and memory routines are used from python2x.dll runtime shouldn't really be used for anything beyond basic dll initialization.

[snaury]

If the problem is only with the runtime, then it looks like I can statically link it. Can you test if this egg works for you? http://kitsu.ru/public/greenlet-0.4.3-py2.7-win-amd64.egg

[snaury]

@grzn of course if you can provide me with x64 bdist_wininst, bdist_egg and bdist_wheel that would be great, thanks!

[grzn]

meaning they don't have the VS2010 runtime so the import fails.
the statically-linked egg works, so that's a better solution to the problem than us building the eggs for you.

[grzn]

Could you please bump the version 0.4.3.1 and upload new binaries?
Thanks

[snaury]

@grzn greenlet 0.4.4 has just been released

[piotr-dobrogost]

@snaury

Yes, as a new maintainer I don't (and don't plan to) have Visual Studio 2008 Professional, and my copy of Visual Studio 2008 Express doesn't have any x64 compilers

Now you can use recently released and free Microsoft Visual C++ Compiler for Python 2.7 available at http://www.microsoft.com/en-us/download/details.aspx?id=44266 See https://mail.python.org/pipermail/distutils-sig/2014-September/024885.html for more details.

Since greenlet doesn't use files and memory routines are used from python2x.dll runtime shouldn't really be used for anything beyond basic dll initialization.

It's pure guessing. I would strongly advise against doing this as there's no guarantee it will work which puts users of such binaries in very bad position.

[snaury]

It's pure guessing.

While I agree having users install a different runtime is inconvenient (which is why I opted for static linking in 0.4.4), after third of my life spent on reverse engineering and malware analysis, there's very little guessing on my part. Especially after I actually start my copy of hiew and verify the code, instead of guessing bad stuff will happen.

Nevertheless I was already planning to use Visual C++ for Python anyway (glad to see setuptools is already released with its support), so thanks for the link.

[snaury]

@grzn newly released 0.4.5 was built with VC++ for Python and dynamic linking, I hope this works for you. Please reopen in case it's not.

[grzn]

Cool.I'll check tomorrow and re-open if there's a problem

Thanks!

—
Sent from Mailbox

On Sat, Oct 18, 2014 at 7:08 PM, Alexey Borzenkov
notifications@github.com wrote:

@grzn newly released 0.4.5 was built with VC++ for Python and dynamic linking, hopes this works for you. Please reopen in case it's not.

Reply to this email directly or view it on GitHub:
#57 (comment)