On 21 August 2013 22:22, Paul Moore <p.f.mo...@gmail.com> wrote: > On 21 August 2013 22:13, Nick Coghlan <ncogh...@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: https://code.google.com/p/numexpr/source/browse/numexpr/cpuinfo.py?r=ac92866e7929df669ca5e4e050179cd7448798f0 $ 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: numpy-1.7.1-cp27-cp22m-win32.whl numpy-1.7.1-cp27-cp22m-win32_sse.whl numpy-1.7.1-cp27-cp22m-win32_sse2.whl numpy-1.7.1-cp27-cp22m-win32_sse3.whl 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? Oscar _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig