<p dir="ltr">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."</p>

<p dir="ltr">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). </p>

<p dir="ltr">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.</p>
<p dir="ltr">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.</p>

<p dir="ltr">I do see a few possible workarounds, but none of them would change the metadata 2.0 standards:</p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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".</p>

<p dir="ltr">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".</p>

<p dir="ltr">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 <a href="http://python.org">python.org</a> Windows 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).</p>

<p dir="ltr">Cheers,<br>
Nick.<br>
</p>