On Tue, Jan 27, 2015 at 1:37 PM, Carl Kleffner firstname.lastname@example.org wrote:
2015-01-27 22:13 GMT+01:00 Nathaniel Smith email@example.com:
On Tue, Jan 27, 2015 at 8:53 PM, Ralf Gommers firstname.lastname@example.org wrote:
On Mon, Jan 26, 2015 at 4:30 PM, Carl Kleffner email@example.com wrote:
Thanks for all your ideas. The next version will contain an augumented libopenblas.dll in both numpy and scipy. On the long term I would prefer an external openblas wheel package, if there is an agreement about this among numpy-dev.
Sounds fine in principle, but reliable dependency handling will be hard to support in setup.py. You'd want the dependency on Openblas when installing a complete set of wheels, but not make it impossible to use:
- building against ATLAS/MKL/... from source with pip or distutils
- allowing use of a local wheelhouse which uses ATLAS/MKL/... wheels
- pip install numpy --no-use-wheel
Static bundling is a lot easier to get right.
In principle I think this should be easy: when installing a .whl, pip or whatever looks at the dependencies declared in the distribution metadata file inside the wheel. When installing via setup.py, pip or whatever uses the dependencies declared by setup.py. We just have to make sure that the wheels we distribute have the right metadata inside them and everything should work.
Accomplishing this may be somewhat awkward with existing tools, but as a worst-case/proof-of-concept approach we could just have a step in the wheel build that opens up the .whl and edits it to add the dependency. Ugly, but it'd work.
My 'delocate' utility has a routine for patching wheels :
pip install delocate delocate-patch --help