[Numpy-discussion] 1.8.1 release
matthew.brett at gmail.com
Wed Feb 26 14:34:28 EST 2014
On Wed, Feb 26, 2014 at 11:02 AM, Chris Barker <chris.barker at noaa.gov> wrote:
> On Wed, Feb 26, 2014 at 8:27 AM, Tom Augspurger <tom.augspurger88 at gmail.com>
>> Thanks for posting those wheels Matthew.
>> I'm on a Mac (10.9.2) and I had trouble installing numpy from your wheel
>> a fresh virtualenv with the latests pip, setuptools, and wheel.
>> $pip install
>> 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
>> 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.
More information about the NumPy-Discussion