[Distutils] pip on windows experience

[David Cournapeau]

On Sun, Jan 26, 2014 at 12:29 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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.
>

I am not speaking for the whole numpy team, but as the former maintainer of
numpy.distutils, I think this will be more hurtful than helpful.

I think the SSE issue is a bit of a side discussion: most people who care
about performance already know how to install numpy. What we care about
here are people who don't care so much about fast eigenvalue decomposition,
but want to use e.g. pandas. Building numpy in a way that supports every
architecture is both doable and acceptable IMO.

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.
>

Building numpy wheels is not hard, we can do that fairly easily (I have
already done so several times, the hard parts have nothing to do with wheel
or even python, and are related to mingw issues on win 64 bits).


> 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).
>

Just to clarify: you actually can install numpy on windows with
python.orginstallers fairly easily by using easy_install already (we
upload a
bdist_wininst compatible binary which should not use any CPU-specific
instructions). It looks like those are missing for 1.8.0, but we can fix
this fairly easily.

David

> Cheers,
> Nick.
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140129/87315003/attachment-0001.html>