> On 8 Dec 2016, at 23:55, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
>
>>
>> On Dec 8, 2016, at 3:37 AM, Ronald Oussoren <ronaldousso...@mac.com
>> <mailto:ronaldousso...@mac.com>> wrote:
>>
>>
>>> On 8 Dec 2016, at 00:40, Glyph Lefkowitz <gl...@twistedmatrix.com
>>> <mailto: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>).
>
> 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
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
