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.
Another idea for the future is to conditionally load a debug version of libopenblas instead. Together with the backtrace.dll (part of mingwstatic, but undocumentated right now) a meaningfull stacktrace in case of segfaults inside the code comiled with mingwstatic will be given.

2015-01-26 2:16 GMT+01:00 Sturla Molden <sturla.molden@gmail.com>:
On 25/01/15 22:15, Matthew Brett wrote:

> I agree, that shipping openblas with both numpy and scipy seems
> perfectly reasonable to me - I don't think anyone will much care about
> the 30M, and I think our job is to make something that works with the
> least complexity and likelihood of error.

Yes. Make something that works first, optimize for space later.


> It would be good to rename the dll according to the package and
> version though, to avoid a scipy binary using a pre-loaded but
> incompatible 'libopenblas.dll'.   Say something like
> openblas-scipy-0.15.1.dll - on the basis that there can only be one
> copy of scipy loaded at a time.

That is a good idea and we should do this for NumPy too I think.


NumPy-Discussion mailing list

NumPy-Discussion mailing list