On 31 May, 2013, at 22:17, Chris Barker - NOAA Federal
HI Folks,
A few of us over on the pythonmac list have been hashing out how best to support binary packages on OS-X. The binary wheel option seems very promising.
However, there is one Mac-specific issue that does not seem to be addressed:
On OS-X, binaries can be "universal" -- what this means is that they have more than one binary architecture embedded in a single file; the system selects the right one at run time. Both executables and dynamic libraries can be universal. In theory, an universal binary can currently contain up to 4 architectures:
This isn't really a problem, distutils uses labels for the set of supported architectures as the architecture label in binary distributions (e.g. pyobjc_core-2.5-py3.4-macosx-10.8-intel.egg for an egg that supports the 'intel' set of architectures (x86_64 and i386), see _osx_support.get_platform_osx in the CPython repository for the labels that are currently used. This is not ideal, but works good enough for now. In the long run this should likely be replaced by the compressed tags sets from PEP 425 (at the cost of a much longer file names). A much more interesting question is which binary wheels should be considered when installing a package, there a two clear ways to select binaries and both have there usecases. Let's say you're running on OSX 10.8 with a CPU that supports x86_64 and a Python installation with support for x86_64, i386 and ppc and compiled with support for OSX 10.4 or later ("MACOSX_DEPLOYMENT_TARGET=10.4"). When installing a package you can pick either: 1) a binary wheel that supports this machine (a wheel compiled with deployment target 10.8 with only x86_64 support) 2) a binary wheel that supports the same systems as the Python installations The former is good enough when you only want to run code on your machine, the latter can be needed when you want to deploy the installed binaries to another machine (for example because you are using py2app to create an application bundle that will be installed elsewhere).
On my system right now, I have 32bitPPC + 32bit i386 universal python, running on an intel system:
In [2]: distutils.util.get_platform() Out[2]: 'macosx-10.3-i386'
On my machine this returns the correct value: 'macosx-10.8-intel' (binary supports 10.8 or later and the i386 and x86_64 architectures). I do know this used to return wrong values on some version of OSX when using the Apple installation of Python because of the way they build Python. Ronald