On 17/08/2019 14:06, Nick Coghlan wrote: > On Thu, 15 Aug 2019 at 03:03, Michael <aixto...@felt.demon.nl> 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. >
signature.asc
Description: OpenPGP digital signature
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/KKNRPX2RH4WVK5ZEY4TOQPM24Y4CQOPP/
