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 <aixtools@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...