On Tue, Jan 27, 2015 at 10:13 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Jan 27, 2015 at 8:53 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
> On Mon, Jan 26, 2015 at 4:30 PM, Carl Kleffner <cmkleffner@gmail.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
>   - etc.
> 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.

Good point, that should work. Not all that much uglier than some of the other stuff we do in release scripts for Windows binaries.