OK.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.