On 24 January 2014 10:18, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 24 Jan 2014 19:41, "Paul Moore" <p.f.moore@gmail.com> wrote:
On 24 January 2014 00:17, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
You need to bear in mind that people currently have a variety of ways to install numpy on Windows that do work already without limitations on CPU instruction set. Most numpy users will not get any immediate benefit from the fact that "it works using pip" rather than "it works using the .exe installer" (or any of a number of other options). It's the unfortunate end users and the numpy folks who would have to pick up the pieces if/when the SSE2 assumption fails.
The people who would benefit are those who (like me!) don't have a core requirement for numpy, but who just want to "try it out" casually, or for experimenting or one-off specialised scripts. These are the people who won't be using one of the curated distributions, and quite possibly will be using a virtualenv, so the exe installers won't work. Giving these people a means to try numpy could introduce a wider audience to it.
Having said that, I can understand the reluctance to have to deal with non-specialist users hitting obscure "your CPU is too old" errors - that's *not* a good initial experience.
And your point that it's just as reasonable for pip to adopt a partial solution in the short term is also fair - although it would be harder for pip to replace an API we added and which people are using, than it would be for numpy to switch to deploying better wheels when the facilities become available. So the comparison isn't entirely equal.
There's also the fact that we're still trying to recover from the setup.py situation (which was a "quick and easy" alternative to a declarative build system), so quick hacks in the core metadata specs that will then be locked in for years by backwards compatibility requirements are definitely *not* acceptable. We already have more than enough of those in the legacy metadata we're aiming to replace :P
It wasn't a totally serious suggestion: I knew what your response would be. ;) I'll try to summarise your take on this: You would like to take the time to ensure that Python packaging is done properly. That may mean that some functionality isn't available for some time, but you think that it's better to "get it right" than rush something out the door just to "get it working fast". That's not an unreasonable position to take but I wanted to contrast that with your advice to numpy: Just rush something out of the door even if it has obvious problems. Don't worry about getting it right; we'll do that later... We all want a solution that definitely works so that you can advise any old noob to use it. So if you could say 'just use pip' then that would be great. But if you say... ''' 'just use pip... unless your CPU doesn't support SSE2. Don't worry if you've never heard of SSE2 just do 'pip install numpy' and then 'python -c "import numpy"'. If you see an error like "your CPU doesn't support SSE2 please install the non-SSE version of numpy." then you'll need to install numpy using one of the other options listed below and make sure that you do that before trying to use pip to install any of these other packages and if you use Cristoph's .exe for numpy then the you can't use pip for scipy and some other set of packages (I'm not totally sure which) so you shouldn't use pip for anything after that. Unless it's a pure Python package. Don't worry if you don't know what a pure Python package is, just try it with pip and if it doesn't work just try something else... """ ... then putting the wheel on PyPI becomes substantially less attractive. Just having to explain that pip might not work and then trying to describe when it will and won't and what to do about it is a pain. I wouldn't want to recommend to my students that they do this unless I was confident that it would work. Also, note that I don't really think a post-install script is the best solution for something like this. It would be better to have an extensible system for querying things like CPU capability. It would also be better to have an extensible system for detecting things like Fortran ABI compatibility - this can also be handled with a post-install script but it's not the best solution. Are there any plans to solve these problems? Also is there a roadmap describing the expected timeline for future packaging features? Oscar