[Distutils] Binary Wheels and "universal" builds on OS-X

Chris Barker - NOAA Federal chris.barker at noaa.gov
Tue Jun 4 18:27:10 CEST 2013


On Tue, Jun 4, 2013 at 1:23 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

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

I think now may be the "long run". But in any case, as we were
discussing, as in theory there could be lots of possible combinations,
in practice there are only two in the wild (plus the non-universal
ones...), and probably only one we really  need to keep supporting, so
simply have a canonical name for the one or two is fine.

> A much more interesting question is which binary wheels should be considered when installing a package,

indeed.

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

can you link a newer deployment target-built lib with an older
deployment-target executable? I guess so...

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

I would say that we should clearly _prefer_ a wheel that fully
supports the pyton the installer is used with.

But I'm a bit ambivalent about what to do if there is no such wheel
found, but there is one that supports the currently running
architecture. I"m inclined to say don't install it:

 - We build the universal binaries to support people that don't want
to know or care about such details.

- We want to support universal binary wheels for those folks.

- The primary reason to build binary wheels at all is to support
non-native architectures -- it's a whole lot easier to simply build
for your current machine, and homebrew and macports, and ??? support
that already.

All that being said, I sometimes think that we should simply have a 32
bit and 64 bit binary out there, and forget all this universal stuff!
It works OK for Windows....

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

This isn't an Apple build -- I'm pretty sure it's the one from
Python.org...though looking now it's only 2.7.2 -- I guess I haven't
upgraded in a while!

now with 2.7.5:

In [3]: distutils.util.get_platform()
Out[3]: 'macosx-10.3-fat'

I guess "fat" means 32bit ppc + intel, deployment target 10.3 ?

So we may want to update distutils.util.get_platform to do a PEP 425
name, but we've got something that could work now.

-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 at noaa.gov


More information about the Distutils-SIG mailing list