I was wondering what is the recommended approach to bundling runtime dll dependencies when using wheels.
We are migrating from egg to wheels for environment installation and of various python dependencies.
Some of those have extension modules, and some have extension modules that depend on the presence
of a third party dll (in our situation, libzmq-v100-mt-4_0_3.dll).
Up to now, these dlls have been installed by the use of the scripts parameter in the setup command of setup.py, but
points to it as not being a good idea.
But the only way to get a dependent dll found on windows is to have it on PATH, and the scripts directory on
windows is on path when a virtualenv is activated.
I have observed two situations:
1) If we use pip wheel to build the wheel, the scripts parameter is ignored and the dlls do not even get to the archive.
2) If we use setup.py bdist_wheel, the dll gets into the archive, but this relies on the non-documented feature of packaging scripts-as-data of dlls.
What is the correct approach at this time ?
I'll post this on the various other lists later, but I promised distutils-sig first taste, especially since the discussion has been raging for a few days (if you're following the setuptools repo, you may already know, but let me take the podium for a few minutes anyway :) )
Microsoft has released a compiler package for Python 2.7 to make it easier for people to build and distribute their C extension modules on Windows. The Microsoft Visual C++ Compiler for Python 2.7 (a.k.a. VC9) is available from: http://aka.ms/vcpython27
This package contains all the tools and headers required to build C extension modules for Python 2.7 32-bit and 64-bit (note that some extension modules require 3rd party dependencies such as OpenSSL or libxml2 that are not included). Other versions of Python built with Visual C++ 2008 are also supported, so "Python 2.7" is just advertising - it'll work fine with 2.6 and 3.2.
You can install the package without requiring administrative privileges and, with the latest version of setuptools (from the source repo - there's no release yet), use tools such as pip, wheel, or a setup.py file to produce binaries on Windows.
The license prevents redistribution of the package itself (obviously you can do what you like with the binaries you produce) and IANAL but there should be no restriction on using this package on automated build systems under the usual one-developer rule (http://stackoverflow.com/a/779631/891 - in effect, the compilers are licensed to one user who happens to be using it on a remote machine).
My plan is to keep the download link stable so that automated scripts can reference and install the package. I have no idea how long that will last... :)
Our intent is to heavily focus on people using this package to produce wheels rather than trying to get this onto every user machine. Binary distribution is the way Windows has always worked and we want to encourage that, though we do also want people to be able to unblock themselves with these compilers.
I should also point out that VC9 is no longer supported by Microsoft. This means there won't be any improvements or bug fixes coming, and there's no official support offered. Feel free to contact me directly <steve.dower(a)microsoft.com> if there are issues with the package.