On Fri, May 15, 2015 at 10:35 PM, Matthew Brett <[email protected]> wrote:
> Hi, > > On Fri, May 15, 2015 at 1:07 PM, Chris Barker <[email protected]> > 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 > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
