In article
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.
As I commented in your pull request, the complete set of universal arch values is "fat", "intel", "fat3", "fat64", and "universal" besides the single arch values "ppc", "ppc64", "i386", and "x86_64". It would be best if all of them were supported in pip.
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/DeveloperT ools/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. [...] 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
Any feedback from experts, especially if my understanding of deployment targets or fat binaries is incorrect, would be much appreciated.
Thanks for actually proposing an implementation of this. I think both changes should be implemented, with the proviso that all universal arch values are supported (for example, the "fat" universal arch is still used in current 32-bit-only python.org Pythons. As I also noted in the comments, it is not a perfect solution since it doesn't cover all possible cases (like Unicode ABI). That will have to wait for Metadata 2.0. But it does provide important usability gains for OS X users right now and covers the most common (by far) use cases. -- Ned Deily, nad@acm.org