[Pythonmac-SIG] PyObjC 3.2 released

[Ronald Oussoren]

> On 8 Dec 2016, at 00:40, Glyph Lefkowitz <glyph at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20161208/c9e165e7/attachment.html>