On 13/08/2019 17:13, Paul Moore wrote: > A couple of quick points: Many thanks for the pointers! > > * You want to focus on setuptools rather than distutils. Setuptools > extends distutils with recent packaging developments, distutils is > essentially just core Python legacy support these days. > * Wheels (built binaries) are typically tagged as manylinux using the > auditwheel project (https://github.com/pypa/auditwheel) although you > are in theory allowed to manually apply the manylinux tag if you can > verify that your wheel conforms to the requirements listed in the > relevant manylinux spec/PEP. > * By default, binaries built on linux are tagged as "linux" which > means "no guarantee that this can be run on any machine other than the > one it was built on". Such wheels cannot be uploaded to PyPI. > * Pip includes rules that let it determine what tags are suitable for > installation on this machine. The details are in > https://packaging.python.org/specifications/platform-compatibility-tags/ > (and that link references PEP 425 as well as the manylinux PEPs for > the details). > > Whether manylinux is relevant for AIX is something you'll have to
"manylinux" per se, is not going to work for AIX - just as it could not
work for FreeBSD, Windows, or macOS, etc.
For a long long time - platform related code on aix was
sys.platform.startswith("aix"), or something similar. FYI: starting with
Python 3.8 - that will still work, but the return value is merely "aix"
- to reflect that since mid 2007 IBM has "guaranteed" binary
compatibility from old to new. So, the manylinux idea will work for AIX
- as long as it is built on an older version of AIX.
So, the parts of manylinux - where they have researched the standard
libs that are binary compatible from old to new is provided by AIX (so
not for OSS libs, as they may have, but should not have, dependencies).
Of course, it gets complex - but looking for light, not darkness :)
> decide. Ultimately it depends on how well the default rules in PEP 425
The PEP speaks about ``distutils.util.get_platform()`` and for AIX -
this is broken. Noone (who loves AIX) has looked at it since 2007 (at
least) when the rules changed, and perhaps since 1999 (or there abouts)
when 64-bit support first appeared (in AIX 4.3).
whether Python 2.7, or Python 3.9 ('master') the value is the same:
root@x066:[/data/prj/python/python3-3.9]./python
Python 3.9.0a0 (heads/pr_13772-dirty:66db707bb0, Aug 12 2019, 18:55:33)
[C] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils
>>> import distutils.util
>>> distutils.util.get_platform()
'aix-6.1'
>>>
So, focusing on the "Platform Tag" - that needs to include more than
what uname -a provides - the tag needs to provide the oslevel TL and SP
(Technology Level, Service Pack) as well as whether it is 32 or 64 bit.
32-bit is still the most common "packaging" for AIX, but it needs to be
specified - imho.
I am guessing - that would be a PR for CPython - to get that into distutils.
I have not read your other pointers (above), but I am going to guess
that what follows would be addressed in setuptools.
My question is - can you verify, or at least agree - that I need to take
up getting the "Platform Tag" corrected in distutils - as a first step?
> manage to ensure that binaries are interoperable, which in turn
> probably depends on how Python typically gets built on AIX, and how
> compatible dynamically linked system libraries are across machines.
>
> Paul
>
> On Tue, 13 Aug 2019 at 15:56, Michael <aixto...@felt.demon.nl> wrote:
>> On 06/08/2019 09:15, Michael wrote:
>> OK - been about a week - so, before I forget everything a list-ping...
signature.asc
Description: OpenPGP digital signature
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/CE3SCZW7HJ2UZ46Q52MGVREFGXY7QXXY/
