[Numpy-discussion] 1.8.1 release

[Matthew Brett]

Hi,

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>
> 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