[Numpy-discussion] binary wheels for numpy?

[Ralf Gommers]

On Fri, May 15, 2015 at 10:35 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Fri, May 15, 2015 at 1:07 PM, Chris Barker <chris.barker at noaa.gov>
> wrote:
> > Hi folks.,
> >
> > I did a little "intro to scipy" session as part of a larger Python class
> the
> > other day, and was dismayed to find that "pip install numpy" still dosn't
> > work on Windows.
> >
> > Thanks mostly to Matthew Brett's work, the whole scipy stack is
> > pip-installable on OS-X, it would be really nice if we had that for
> Windows.
> >
> > And no, saying "you should go get Python(x,y) or Anaconda, or Canopy,
> or...)
> > is really not a good solution. That is indeed the way to go if someone is
> > primarily focusing on computational programming, but if you have a web
> > developer, or someone new to Python for general use, they really should
> be
> > able to just grab numpy and play around with it a bit without having to
> > start all over again.
> >
> >
> > My solution was to point folks to Chris Gohlke's site -- which is a
> Fabulous
> > resource --
> >
> > THANK YOU CHRISTOPH!
> >
> > But I still think that we should have the basic scipy stack on PyPi as
> > Windows Wheels...
> >
> > IIRC, the last run through on this discussion got stuck on the "what
> > hardware should it support" -- wheels do not allow a selection at
> installc
> > time, so we'd have to decide what instruction set to support, and just
> stick
> > with that. Which would mean that:
> >
> > some folks would get a numpy/scipy that would run a bit slower than it
> might
> > and
> > some folks would get one that wouldn't run at all on their machine.
> >
> > But I don't see any reason that we can't find a compromise here -- do a
> > build that supports most machines, and be done with it. Even now, people
> > have to go get (one way or another) a MKL-based build to get optimum
> > performance anyway -- so if we pick an instruction set support by, say
> (an
> > arbitrary, and impossible to determine) 95% of machines out there --
> we're
> > good to go.
> >
> > I take it there are licensing issues that prevent us from putting Chris'
> > Binaries up on PyPi?
>
> Yes, unfortunately we can't put MKL binaries on pypi because of the
> MKL license - see
>
> https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows#blas--lapack-libraries
> .
> Also see discussion in the containing thread of
> http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069701.html
> .
>
> > But are there technical issues I'm forgetting here, or do we just need to
> > come to a consensus as to hardware version to support and do it?
>

There's the switch to OpenBLAS and building the right selection mechanism
for which arch to use:
http://article.gmane.org/gmane.comp.python.distutils.devel/20350. That
seems now feasible to complete on a reasonable time-scale, and the problems
with OpenBLAS seem to be mostly solved. Binaries which crash for ~1% of
users (which ATLAS-SSE2 would result in) are still not acceptable I think.

Ralf


> There has been some progress on this - see
>
> https://github.com/scipy/scipy/issues/4829
>
> I think there's a move afoot to have a Google hangout or similar on
> this exact topic :
> https://github.com/scipy/scipy/issues/2829#issuecomment-101303078 -
> maybe we could hammer out a policy there?  Once we have got numpy and
> scipy built in a reasonable way, I think we will be most of the way
> there...
>
> Cheers,
>
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150517/42801e31/attachment.html>