Hi, On Wed, Feb 26, 2014 at 11:02 AM, Chris Barker <chris.bar...@noaa.gov> wrote: > On Wed, Feb 26, 2014 at 8:27 AM, Tom Augspurger <tom.augspurge...@gmail.com> > wrote: >> >> Thanks for posting those wheels Matthew. >> >> I'm on a Mac (10.9.2) and I had trouble installing numpy from your wheel >> in >> a fresh virtualenv with the latests pip, setuptools, and wheel. >> >> ``` >> $pip install >> ~/Downloads/numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl >> numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_9_intel.whl is not a supported >> wheel on this platform. >> Storing debug log for failure in /Users/admin/.pip/pip.log >> ``` > > > IIRC, those wheels are built for the pyton.org builds of python: > > macosx_10_9 means it was built on 10.9 (though that should be 10.6, I > think, as it is built FOR 106+, not only 10.9..) > > _intel means it's an Intel build, which in the nomenclature used in the > pyton.org builds, means it's a universal 32 and 64 bit Intel > > >> >> When I build a wheel from source, my platform is `x86_64`. > > > What python are you using? apparently not a Universal 32+64 bit build. The > one Apple delivers? > >> ``` >> $mv numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_intel.whl >> numpy-1.8.0.dev_a89a36e-cp27-none-macosx_10_6_x86_64.whl >> ``` >> >> and then running `pip install` on that wheel successfully installed numpy >> (and the test suite passed). > > > I'm not entirely sure we can count on that working, as I _think_ the SDK > that the wheel was built against is different than the one your python was > built against. > > But it theory, one should be able to install a universal wheel into a > one-of-the-architectures build, the other one will get ignored (as it seems > to be for you), but I think it's fragile in general. > > This is a serious issue with binary wheels -- there are so many variations > to a "platform" -- the naming scheme covers OS, OS version, and bit depth, > but not system library versions, and who the heck knows what else. > > This has been discussed a lot on the dist_utils list, with no real solution > in sight: > - there are other alternative, for instance, I think conda packages have > some sort of hash or something to make sure that binary packages all match. > > - convention is the other option: > - use binary wheel for in-house deplyment to similar systems > - use binary wheels for a well-defined python build: > - for PyPi, that's the python.org builds for Windows and OS-
Thanks - that is a very useful summary. It would make sense I think to provide numpy wheels like mine via pypi - as pyzmq does for example. In this case, I believe (Chris correct me if I'm wrong) that someone running via system python would get the usual compile / install, but someone running python.org python would get a near instant numpy, so that seems like a clear win. Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
