Re: distutils.util.get_host_platform() and AIX

Michael <[email protected]> Sun, 18 Aug 2019 13:30:18 +0200
Newsgroups	gmane.comp.python.distutils.devel
Message-ID	<[email protected]>
On 17/08/2019 14:06, Nick Coghlan wrote:
> On Thu, 15 Aug 2019 at 03:03, Michael <[email protected]> wrote:
>> 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.
>>
>> OK.
>>
>> 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.

Would be 'nice' if old meant 3.6 and earlier as I would like to target
3.7 and later.

PEP425 would not, imho, be contradicted - as it says "The platform tag
is simply distutils.util.get_platform() with all hyphens - and periods .
replaced with underscore _."

My belief is that the current implementation for AIX is insufficient.
e.g., it does not even include 32/64 bitness.

I think I read your comment re:
https://packaging.python.org/specifications/platform-compatibility-tags/

better, and I wonder how that would be done: a modification to the
document (platform-compatibility-tags), or something else? The current
information talks about the use of a psuedo-tag because the scheme
defined in PEP425 - for linux - did not work for *linux* platform tags.

I have done my research, and have a good idea of how and where to
collect and store "build" related information, versus "run-time"
information. For the record, I notice that sysconfig.get_platform() and
distutils.util.get_platform() are 'real-time' oriented.

So, I see no need to alter the nature of sysconfig.get_platform() or
distutils.util.get_platform() - they can stay run-time. But some
additional information needs to be provided. So, where is the best place
to discuss what these system changes *should* be.

>
> So, on the publishing side, at least setuptools and wheel will need
> updating to generate wheel archive properly for AIX.
Nods.
> On the installation side, at least pip and the packaging project will
> need updating to generate the correct set of candidate platform tags.

I am looking at the links Paul suggested, and that gave me the food for
thought needed to come up with an algorithm as you suggested.

Trying to not repeat many communicative errors I made years back -
getting something I saw as a bug-fix, but Python saw as a feature change
- I am trying hard to get the discussion started properly. As to
Python3.7 and Python3.8 - I am happy with a "maybe". I do not think it a
correct approach if I were to make proposals for pip, setuptools and
wheel projects that take - what Python gives is insufficient. And, I
still need 'something' in Cpython, even if it is only a define in
sysconfig.get_vars() so that there is a "build" related value. FYI
GNU_HOST_TYPE is nearly complete for what is needed. But I slip towards
details - so I'll stop for now.

Reiterating - continue only here, or expand and include python-dev?

Michael

> Cheers,
> Nick.
>

--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/archives/list/[email protected]/message/KKNRPX2RH4WVK5ZEY4TOQPM24Y4CQOPP/
signature.asc (application/pgp-signature, 488 B)