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? On May 31, 2013 6:30 PM, "Chris Barker - NOAA Federal" < [email protected]> wrote:
> 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: > > 32+64 bit PPC and 32+64bit x86 > > In practice, 64 bit PPC was never broadly used, and 32bit PPC is > fading fast. Nevertheless, both 32 and 64 Intel systems are pretty > common, and who knows what there may be in the future (you never know > with Apple...) > > The binary builds of Python served up on the python.org web site have > supported universal builds for years -- currently there are two > options: 32bit PPC+x86 or 32+64bit x86. It's not a single build, as it > turns out it's hard to support both up to date x86_64 and PPC with the > same compiler. In these builds, the configuration is set up so that > distutils will build universal extensions that match the architectures > included in the builds. This makes it pretty easy to build binary > packages, and/or full app distributions (py2app) that are universal as > well. > > setuptools' easy_install supports binary eggs, but always choked on > universal builds -- it didn't know how to identify what matched the > system. It would be really nice if future tools could identify and > install the correct binary wheels for universal builds. > > I've taken a look at PEP 427, and see this: > > platform tag > E.g. 'linux_x86_64', 'any'. > > That looks to me like there is a built-in assumption that a wheel is > either specific to a single architecture, or any -- so no way to > specify that it may have multiple architectures. So I propose that > platform tag allow a list of some sort: > > ['macosx-10_6_i386', 'macosx_10_6-x86_64'] > > or, I suppose to keep it simple, a single string: > > 'macosx_10_6_i386+macosx_10_6_x86_64' > or > 'macosx_10_6_i386+x86_64' > > If so, then a binary wheel could be built (and discovered) that > supported multiple architectures. > > Then how would an installer ( pip? ) identify the right one? This is a > bit tricky. PEP 425 states: > > "The platform tag is simply distutils.util.get_platform() with all > hyphens - and periods . replaced with underscore" > > 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' > > So we may want to patch get_platform() to support universal builds - > or add anther function or something -- you may sometimes what to know > what you are running right now, and other times want to know how the > current python is built. (note that while distutils can build > universal binaries, it's not very smart about it -- all is does is > grab the compiler and linker flags from the Makefile, which include > multiple "-arch" flags. > > Even if there is an easy way to query the system, that leaves the > question of what to do. If a user wants to intall a package into a > universal python, will the installer only accept a binary wheel with > all the supported architectures? or one with only the currently > running one? > > Anyway, it would be nice to be able to get this stuff to "just work" > with universal binaries on the Mac. > > Thoughts, ideas? > > -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 > > [email protected] > _______________________________________________ > Distutils-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
