Hi, On Wed, Feb 26, 2014 at 11:02 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, Feb 26, 2014 at 8:27 AM, Tom Augspurger <tom.augspurger88@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