I am guessing - that would be a PR for CPython - to get that into distutils.

Not really, since the platform tag generation needs to work on older
Python versions.

Instead, you'll want to define a new algorithm for deriving the
platform tag on AIX that can be referenced from
https://packaging.python.org/specifications/platform-compatibility-tags/

You shouldn't have the same challenges that manylinux did when it
comes to determining a suitable build environment, though - IBM are
already doing that work for AIX, just as MS do it for Windows, and
Apple do it for Mac OS X.

I am probably missing something that is right in front of me.

By "new algorithm" for generating a platform tag - I thought that would have been a PR to update the *.get_platform(). What should go into that seems fairly straight-forward to me. And it would/should reflect the "build environment" provided by IBM_AIX.

But when I read https://packaging.python.org/specifications/platform-compatibility-tags/ I have the impression I am tasked with generating a new "tag", e.g., manyaix.

I do not think a new pseudo-tag is needed - if the tag is generated properly. The danger comes from, e.g., a Python 3 executable built on AIX 7.1 and someone builds a module on AIX 7.2. Chances are (read I would expect) the module would not work on AIX 7.1. This is two different moments in time, lets assume two different 'packagers'.

I can play around on my own - learning curve - using the tag as it is for now. I suspect that noone "AIX oriented" is using either eggs or wheels. They may be trying the format RPM (I tried with cffi and that format failed to complete) but others succeed. Just no wheels.

And, is it a bug? if I use ./setup.py bdist -b aix-SOMETHING because in the dist directory the filenames are all using aix-6.1 where the platform tag is expected. All I see is that the directory aix-SOMETHING exists, and there is a message that aix-SOMETHING/dumb is removed.

Regards,

Michael