> On Dec 8, 2016, at 3:37 AM, Ronald Oussoren <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.
>> 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 :-).
-glyph
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
