<p dir="ltr">Wheel already supports compound tags. Just like py2.py3-none-any a tag py3-none-x86.ppc (with real platform names) would work. Does that make sense for Mac?</p>
<div class="gmail_quote">On May 31, 2013 6:30 PM, "Chris Barker - NOAA Federal" <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
HI Folks,<br>
<br>
A few of us over on the pythonmac list have been hashing out how best<br>
to support binary packages on OS-X. The binary wheel option seems very<br>
promising.<br>
<br>
However, there is one Mac-specific issue that does not seem to be addressed:<br>
<br>
On OS-X, binaries can be "universal" -- what this means is that they<br>
have more than one binary architecture embedded in a single file; the<br>
system selects the right one at run time. Both executables and dynamic<br>
libraries can be universal. In theory, an universal binary can<br>
currently contain up to 4 architectures:<br>
<br>
32+64 bit PPC and 32+64bit x86<br>
<br>
In practice, 64 bit PPC was never broadly used, and 32bit PPC is<br>
fading fast. Nevertheless, both 32 and 64 Intel systems are pretty<br>
common, and who knows what there may be in the future (you never know<br>
with Apple...)<br>
<br>
The binary builds of Python served up on the <a href="http://python.org" target="_blank">python.org</a> web site have<br>
supported universal builds for years -- currently there are two<br>
options: 32bit PPC+x86 or 32+64bit x86. It's not a single build, as it<br>
turns out it's hard to support both up to date x86_64 and PPC with the<br>
same compiler. In these builds, the configuration is set up so that<br>
distutils will build universal extensions that match the architectures<br>
included in the builds. This makes it pretty easy to build binary<br>
packages, and/or full app distributions (py2app) that are universal as<br>
well.<br>
<br>
setuptools' easy_install supports binary eggs, but always choked on<br>
universal builds -- it didn't know how to identify what matched the<br>
system. It would be really nice if future tools could identify and<br>
install the correct binary wheels for universal builds.<br>
<br>
I've taken a look at PEP 427, and see this:<br>
<br>
platform tag<br>
E.g. 'linux_x86_64', 'any'.<br>
<br>
That looks to me like there is a built-in assumption that a wheel is<br>
either specific to a single architecture, or any -- so no way to<br>
specify that it may have multiple architectures. So I propose that<br>
platform tag allow a list of some sort:<br>
<br>
['macosx-10_6_i386', 'macosx_10_6-x86_64']<br>
<br>
or, I suppose to keep it simple, a single string:<br>
<br>
'macosx_10_6_i386+macosx_10_6_x86_64'<br>
or<br>
'macosx_10_6_i386+x86_64'<br>
<br>
If so, then a binary wheel could be built (and discovered) that<br>
supported multiple architectures.<br>
<br>
Then how would an installer ( pip? ) identify the right one? This is a<br>
bit tricky. PEP 425 states:<br>
<br>
"The platform tag is simply distutils.util.get_platform() with all<br>
hyphens - and periods . replaced with underscore"<br>
<br>
On my system right now, I have 32bitPPC + 32bit i386 universal python,<br>
running on an intel system:<br>
<br>
In [2]: distutils.util.get_platform()<br>
Out[2]: 'macosx-10.3-i386'<br>
<br>
So we may want to patch get_platform() to support universal builds -<br>
or add anther function or something -- you may sometimes what to know<br>
what you are running right now, and other times want to know how the<br>
current python is built. (note that while distutils can build<br>
universal binaries, it's not very smart about it -- all is does is<br>
grab the compiler and linker flags from the Makefile, which include<br>
multiple "-arch" flags.<br>
<br>
Even if there is an easy way to query the system, that leaves the<br>
question of what to do. If a user wants to intall a package into a<br>
universal python, will the installer only accept a binary wheel with<br>
all the supported architectures? or one with only the currently<br>
running one?<br>
<br>
Anyway, it would be nice to be able to get this stuff to "just work"<br>
with universal binaries on the Mac.<br>
<br>
Thoughts, ideas?<br>
<br>
-Chris<br>
<br>
<br>
<br>
--<br>
<br>
Christopher Barker, Ph.D.<br>
Oceanographer<br>
<br>
Emergency Response Division<br>
NOAA/NOS/OR&R (206) 526-6959 voice<br>
7600 Sand Point Way NE (206) 526-6329 fax<br>
Seattle, WA 98115 (206) 526-6317 main reception<br>
<br>
<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a><br>
_______________________________________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">http://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote></div>