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.

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?