> On 8 Dec 2016, at 00:40, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: >> >> >> Last time I checked systems like Homebrew only build 64-bit binaries (on >> anything resembling modern hardware). It should be possible to support both >> i386/x86_64 python.org <http://python.org/> and homebrew using the same >> wheel file by tweaking the platform tag. The filename of the wheels will get >> annoyingly long, but that’s something users won’t see anyway. If that >> doesn’t work out I’ll install homebrew on my build machine and have the >> build script generate wheels for that as well. > > You shouldn't need to do this; and in fact you shouldn't do it :). If you > tweak the platform tag, you'll break Pip's ability to discover the wheel as > valid-to-install for the current platform. Platform tags are a descriptive > mechanism for Python, Pip, and Setuptools, not a point for user extensibility.
I know how platform tags work, I’ve read the relevant PEPs when the were proposed. The “tweak” I wanted to use is documented as “Compressed Tag Sets” in PEP 425, and is how the python version is added to the wheel filename for wheels supporting both python2 and python3, as in: pyobjc_framework_XgridFoundation-3.3a0-py2.py3-none-any.whl This should work in the platform tag as well, and is already used by wheels for matplotlib (see https://pypi.python.org/pypi/matplotlib <https://pypi.python.org/pypi/matplotlib>). > > > There are a lot of fiddly nuances here, but basically, "intel" is the > architecture for "fat binary, intel", and "x86_64" is the architecture for > "64-bit". (I have no idea what the story is on 10.5 and previous but IMHO > you can skip bothering to build wheels for them for now). If you want to > build release wheels, just build "intel" (fat binary) and any Python will be > happy with them. I wrote the distutils code that sets the platform to a sane value for fat binaries on OSX ;-). > > Regardless of what architecture you run it under - and I did test this before > sending this message :) - system python will produce _intel wheels; Homebrew > produces _x86-64 wheels. Cracking one open, this is what both 32- and 64-bit > system python built: > > $ file CoreFoundation/_CoreFoundation.so > CoreFoundation/_CoreFoundation.so: Mach-O universal binary with 2 > architectures: [i386: Mach-O bundle i386] [x86_64: Mach-O 64-bit bundle > x86_64] > CoreFoundation/_CoreFoundation.so (for architecture i386): Mach-O bundle > i386 > CoreFoundation/_CoreFoundation.so (for architecture x86_64): Mach-O 64-bit > bundle x86_64 > > and this is what Homebrew built: > > $ file CoreFoundation/_CoreFoundation.so > CoreFoundation/_CoreFoundation.so: Mach-O 64-bit bundle x86_64 > > Homebrew could happily 'pip install *.whl' in the directory of _intel wheels > built by system Python, and I imported the module and made a couple of objc > method calls, which worked fine, just to make double extra sure my > understanding is correct. That’s cool, this means pip did implement the logic that’s needed to understand that “intel” is an acceptable architecture when looking for a wheel for an “x86_64” build of CPython. > > This is probably worth reading, as it explains the above in a lot more > detail: https://github.com/MacPython/wiki/wiki/Spinning-wheels > <https://github.com/MacPython/wiki/wiki/Spinning-wheels>. But the lede is: > just use the default behavior of a fat binary Python, it will do the right > thing :). Looking at that page the relevant logic was added in pip 6, that’s old enough to not worry about using a compressed tag set for the platform. Ronald
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
