Re: [Pyobjc-dev] [Pythonmac-SIG] PyObjC 3.2 released

[Ronald O. <ron...@ma...>]

> On 8 Dec 2016, at 23:55, Glyph Lefkowitz <gl...@tw...> wrote:
> 
>> 
>> On Dec 8, 2016, at 3:37 AM, Ronald Oussoren <ron...@ma... <mailto:ron...@ma...>> wrote:
>> 
>> 
>>> On 8 Dec 2016, at 00:40, Glyph Lefkowitz <gl...@tw... <mailto:gl...@tw...>> 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>).
> 
> Aah, I was reading you backwards.  I thought you were saying something about inventing a platform tag for Homebrew (since they don't have one of their own; they build specifically to be compatible with system python).  This makes sense.

That explains the confusion.
> 
>>> 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 ;-).  
> 
> Heh. I think we both know a little too much about this for our own good :-).
> 
>> 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.
> 
> I believe it understands the tags pretty thoroughly; I haven't tested, but I believe it also knows that an x86_64 wheel won't cut it on an 'intel' python because it might blow up later.
> 
>>> 
>>> 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. 
> 
> Cool.  I'm really looking forward to never building pyobjc again :-).

:-)

I’ve written some scripts to help me with doing the release, by scaling back the scope these scripts got a lot simpler and more importantly actually got written.  

Annoyingly the testsuite runner found some issues that I had missed before because I don’t regularly all python versions and architectures. The new test runner should make it a lot easier to do comprehensive testing, a test run will still take a lot of time but I won’t have to be present for that. 

Ronald