On Thu, Mar 6, 2014 at 1:14 PM, Matthew Brett <[email protected]>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 [email protected]
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
