On Thu, 15 Aug 2019 at 03:03, Michael
On 14/08/2019 15:09, Nick Coghlan wrote:
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'.
It doesn't need to be a new pseudo-tag, it just needs to account for the fact that distutils.get_platform() in the standard library won't be changed to return a different answer on AIX when running older versions of Python. So, on the publishing side, at least setuptools and wheel will need updating to generate wheel archive properly for AIX. On the installation side, at least pip and the packaging project will need updating to generate the correct set of candidate platform tags. Cheers, Nick. -- Nick Coghlan | firstname.lastname@example.org | Brisbane, Australia