[Distutils] What does it mean for Python to "bundle pip"?

Oscar Benjamin oscar.j.benjamin at gmail.com
Thu Aug 22 13:24:01 CEST 2013

On 21 August 2013 22:22, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21 August 2013 22:13, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Wheel is a suitable replacement for bdist_wininst (although anything that
>> needs install hooks will have to wait for wheel 1.1, which will support
>> metadata 2.0). It's just not a replacement for what hashdist and conda let
>> you do when you care more about reproducibility than you do about security
>> updates.
> OK, that's a good statement - wheels as a better bdist_wininst is all I want
> to be able to promote (and yes, if you need post-install hooks, wait for
> wheel 1.1).

Okay, so going back to my earlier question...

Oscar asked:
> BTW is there any reason for numpy et al not to start distributing
> wheels now? Is any part of the wheel
> specification/tooling/infrastructure not complete yet?

the answer is basically yes to both questions.

The pip+PyPI+wheel infrastructure is not yet able to satisfy numpy's
needs as the wheel spec doesn't give sufficiently fine-grained
architecture information and there's no way to monkey-patch the
installation process in order to do what the current installers do.

It seems to me that the ideal solution for numpy is not really the
post-install script but a way to distribute wheels appropriate to the
given CPU. Bundling the different binaries in one installer makes
sense for an installer that is manually downloaded by a user but not
for one that is automatically downloaded.

There's a pure Python script here that seems to be able to obtain the
appropriate information:

$ python cpuinfo.py
CPU information: CPUInfoBase__get_nbits=32 getNCPUs=2 has_mmx has_sse2
is_32bit is_Core2 is_Intel is_i686

So perhaps numpy could upload multiple wheels:


Then ordinary pip would just install the win32 wheel but "fancypip"
could install the one with the right level of sse2 support.

Or is there perhaps a way that a distribution like numpy could depend
on another distribution that finds CPU information and informs or
hooks into pip etc. so that pip would be able to gain this support in
an extensible way?


More information about the Distutils-SIG mailing list