On Thu, Mar 6, 2014 at 1:14 PM, Matthew Brett <matthew.brett@gmail.com> wrote:

I believe that the wheels built against python.org python will in any
case work with system python.

IIUC, the system python is built agains an up-to-date SDK. so it wouldn't run on an older OS version -- and why would anyone want it to -- it comes with the system.

Our wheels are built with the 10.6 SDK -- OS-X is supposed to be backward compatible, so 10.6 SDK code will run on newer OS versions -- but could there be any clashes if a shared lib is linked in that uses a different SDK than the host application? I have no idea if this is expected to be robust -- though the linker doesn't given an error -- so maybe.

I've just tested the wheel I built [1] on a 10.7 machine in a system
python virtualenv - all tests pass.

Good start.

In any case, unless we do something extra, the built wheel won't
install into system python by default, because the wheel name can't
match the name system python expects. Here I tested the situation I'd
expect when the wheel is on pypi, by downloading the wheel to the
current directory of a 10.7 machine and:

pip install --pre --find-links . numpy

pip doesn't accept the wheel and starts a source install. This is
because of the platform tag [2]. System python expects a platform tag
that matches the result of `distutils.util.get_platform()`. The
python.org builds always have `10_6_intel` for this. On a 10.7
machine:

System python has the actual OSX version. On 10.7 again:

$ /usr/bin/python -c "import distutils.util;
print(distutils.util.get_platform())"
macosx-10.7-intel

interesting -- the "intel" part of that means is SHOULD be a universal binary with 32 and 64 bit in there. And on my 10.7 system, it is. So maybe this should work.

In fact, if I rename my wheel from
`numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.whl` to
`numpy-1.8.1rc1-cp27-none-macosx_10_6_intel.macosx_10_7_intel.whl`,
system python will pick up this wheel, but obviously this could get
boring for lots of OSX versions, and in any case, it's not really our
target market for the wheels. [4]

Exactly, though if we can support it easily, maybe good to do.

Min RK actually has a pull request in to relax this OSX version
specificity [3] because the wheels should be (and seem to be)
interoperable, but the take-home is that we're not likely to run into
trouble with system python.

If we relax things too much, will we also get homebrew and macports and built-it-myself pythons, and will they work?

-Chris

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA 98115   (206) 526-6317   main reception

Chris.Barker@noaa.gov