I've also run into similar issues. What I do with PEX is fudge PEP425 tags for OS X in order to be more correct: https://github.com/wickman/commons/blob/wickman/pep425/src/python/twitter/common/python/pep425.py
The current version on master (not wheel-aware) does it slightly differently for eggs, but it's exactly the same idea: https://github.com/twitter/commons/blob/master/src/python/twitter/common/python/platforms.py I'd love if some variation of this code could be added to setuptools or whatever. ~brian On Thu, Mar 6, 2014 at 4:27 PM, MinRK <benjami...@gmail.com> wrote: > Hello, > > I proposed a patch <https://github.com/pypa/pip/pull/1465> to pip, with > respect to treatment of the platform tag on OS X, and Chris Barker proposed > that I bring the discussion here. > > The situation: > > PEP 425 describes the platform tag as: > > The platform tag is simply distutils.util.get*platform() with all hyphens > - and periods . replaced with underscore *. > > but the PEP makes no mention of what should be done on OS X. On OS X, > get_platform() has the form: > > macosx_10_6_intel > > where 10_6 indicates that the OS X deployment target (of Python) is 10.6, > and intel indicates that it is a fat binary with both x86_64 and i386. > Other values for the arch include 'ppc', 'ppc64', and 'universal', another > multi-arch tag indicating a fat binary with all four of 32/64bit intel and > ppc. > > Where PEP 425 causes problems (or pip's implementation thereof), is in > testing strict equality of this value, not taking into account the meaning > of its contents. I proposed two changes: > > 1. > > Use >= comparison for the deployment target > > From the OS X platform > documentation<https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html> > : > > Choose a deployment target. This identifies the earliest OS version on > which your software can run. > > so a binary with deployment target = 10.6 should be installable on OS > X >= 10.6. > > This change restores the longstanding behavior of easy_install, where > 10.6 eggs are installable on >= 10.6. > 2. > > support multi-arch names (intel, universal) on their respective > components > - intel is valid on {x86_64, i386} > - universal is valid on {intel, x86_64, i386, ppc64, ppc} > > easy_install, like pip, also does strict comparison here, so this > would be new behavior. > > My actual use case: > > I have a wheel (pyzmq), which works on any intel-based Python targeting OS > X >= 10.6. To express this with pip-1.5, the filename has to be: > > > pyzmq-14.1.0-cp27-none-macosx_10_6_intel.macosx_10_6_x86_64.macosx_10_6_i386.macosx_10_7_intel.macosx_10_7_x86_64.macosx_10_7_i386.macosx_10_8_intel.macosx_10_8_x86_64.macosx_10_8_i386.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_9_i386.whl > > and it has to grow every time there is a new OS release. > > With both proposed changes, I could communicate the same information with > just one tag: > > pyzmq-14.1.0-cp27-none-macosx_10_6_intel.whl > > With just the first change, it would need three: > > > pyzmq-14.1.0-cp27-none-macosx_10_6_intel.macosx_10_6_x86_64.macosx_10_6_i386.whl > > Any feedback from experts, especially if my understanding of deployment > targets or fat binaries is incorrect, would be much appreciated. > > Thanks, > > -MinRK > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig