[Distutils] pip on windows experience

[Nick Coghlan]

Paul's position exactly mirrors my own - I an perfectly fine with the
recommended advice to scientific users continuing to be "NumPy doesn't
officially support pip and virtualenv because of the way it is built and
installed, so you will have to get one of the curated scientific stacks,
bootstrap conda, use the Windows installers or use the version provided by
your Linux distro vendor."

The metadata 2.0 standards *will not* be accepted until the pip 1.6 or 1.7
time frame, and it's more likely the latter, since I don't want to distract
anyone from the current security work (I know I said otherwise recently,
but I managed to temporarily forget that the Warehouse transition and
implementing PEP 458 was next on the to do list when I said that).

So, if the NumPy community choose to wait for general post-install script
support in wheel files, they're likely to be waiting at least until the
release of pip 1.7.

In the meantime, the failure mode for people attempting to try out the
Scientific Python stack via "pip install numpy" in an existing Python
installation or virtualenv will remain a failure to build with a likely
cryptic error.

I do see a few possible workarounds, but none of them would change the
metadata 2.0 standards:

1. Add explicit NumPy support *directly* to pip. This would be the quick
hack, private API support that Oscar is requesting, since it would be a
special arrangement between the pip devs and the numpy devs, and eventually
replaced by a general purpose post-install mechanism in metadata 2.0.

2. Add support to pip to request the conversion of available wininst
installers (and bdist_dumb?) to wheels for installation with pip. Vinay has
this working from a technical perspective, so it may be something the pip
devs are interested in exploring for pip 1.6.

3. Both of the above options require waiting for pip 1.6 (at the earliest),
which means neither will improve the behaviour in CPython 3.4 (which will
ship pip 1.5.1). The only folks with the power to improve *that* situation
are the NumPy devs, who have the ability to choose between the "doesn't
work for anyone except experienced build engineers" status quo and "works
for a large percentage of users, but will still fail at runtime for users
on hardware without SSE2 support".

To put the "but what if the user doesn't have SSE2 support?" concern in
context, it should only affect Intel users with CPUs older than a Pentium 4
(released 2001), and AMD users with a CPU older than an Opteron or Athlon
64 (both released 2003). All x86/x86_64 CPUs released in the past decade
should be able to handle SSE2 binaries, so our caveat can be "if your
computer is more than a decade old, 'pip install numpy' may not work for
you, but it should do the right thing on newer systems".

Now, the NumPy devs may feel that persisting with the status quo for
another 6 to 12 months while waiting for still hypothetical additional
changes in pip specifically to accommodate NumPy's current installation
practices is a better alternative than taking option 3. However, from my
perspective, having NumPy readily available to users using the
python.orgWindows installers for Python 3.4 would *significantly*
lower the barrier
to entry to the Scientific Python stack for new users on relatively modern
systems when compared to the 4 current options (while we accept the Linux
distro problem is on distutils-sig to deal with, that's far from being a
NumPy specific problem).

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140126/7d922f70/attachment-0001.html>