[Distutils] pip on windows experience

[Oscar Benjamin]

On 24 January 2014 10:18, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 24 Jan 2014 19:41, "Paul Moore" <p.f.moore at gmail.com> wrote:
>>
>> On 24 January 2014 00:17, Oscar Benjamin <oscar.j.benjamin at 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