Many thanks for the pointers!A couple of quick points:
* 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
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
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 <firstname.lastname@example.org> wrote:On 06/08/2019 09:15, Michael wrote: OK - been about a week - so, before I forget everything a list-ping...