distutils.util.get_host_platform() and AIX

Michael <[email protected]> Thu, 1 Aug 2019 11:07:31 +0200
Newsgroups	gmane.comp.python.distutils.devel
Message-ID	<[email protected]>
Recently I have become more interested in looking at how to simplify
packaging for AIX.

Currently I more or less ignore anything pip and/or distutils could mean
for a python "user" (e.g., AIX sys admin and/or Python developer working
on AIX) as I just run "pip install XYZ" locally, find what constitutes
the equivalent of a bdist, and repackage those as 'installp' packages.

For someone with root access this is ok - as installp requires root (or
RBAC equivalent) to install.

As I would like to make installing modules more Python like - I asked
around and was pointed at piwheels (which looks very useful for my
aspiration) but also at PEP425 and the platform-tag.

There are several things I need to learn about dist-utils, and how
packaging tagging needs to be considered when, e.g., Python is built on
AIX 7.1 and the module is built on AIX 7.2 - there may be AIX ABI
differences that would prevent the module built on AIX 7.2 from working
properly on AIX 7.1 while the same module built on AIX 7.1 will run with
no issue on AIX 7.2. (A simplified explanation is that libc.a on AIX 7.2
knows how to work with applications linked against libc.a from earlier
versions of AIX, but earlier versions of AIX do not know how to deal
with libc.a from AIX 7.2.)

Taken to an extreme: Python(2|3) and modules built on AIX 5.3 TL7 run,
unaltered, on all levels of AIX including the latest AIX 7.2 - while my
expectation is that executable and modules built on AIX 7.2 TL5 (latest
level) might not run on AIX 7.2 TL4.

In short, "version", "release" are in themselves not enough - the TL
(technology level) should also be considered.

Additionally, what I also see "missing" is the
platform.architecture()[0] value. By default, this is still 32bit on AIX
- but it is important - especially for pre-built eggs and/or wheels.

In the AIX world - the OS-level name scheme is usually: VR00-TL-SP
(Version, Release, TechnologyLevel, ServicePack). There is also a value
compareable to a builddate, but for distutils purposes has no value (I
can think of).

So, to my question: currently, for AIX get_host_platform returns
something such as: aix-6.1.

Considering above: what would you - as more expericenced with
multi-oslevel packaging and low levels are accepted by high-levels, but
not v.v.
"What should the AIX get_host_platform() string contain?"

At a minimum I forsee:        return "%s-%s.%s-%s" % (osname, version,
release, platform.architecture()[0])

But this does not address potential issues where the TL level within a
version.release has changed. (X.Y.TL5 built packages MIGHT work on
X.YTL4, but there is no reason to expect them to.

So, I would look to something that remains recognizable, but uses
different 'punctuation'

e.g., oslevel -s returns a string such as: 6100-09-10-1731

Then using the equivalent of:

version, release, service, builddata = '6100-09-10-1731'.split('-')

return "%s-%s.%s.%s-%s" % (osname, version, release, service,
platform.architecture()[0])

Note: no special authority is needed to run "oslevel -s", but it does
take time. So having a way, in the library to only have to actually call
for the value once - is a great improvement. I can imagine a way to do
it (store a static value somewhere, and when it is NULL aka not
initialized call the program, otherwise return the value) - but "WHERE"
- in distutils, or (ideally?) elsewhere in a more "central" library.

Sincerely,

Michael

--
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/5QELRWSQ2XFIDDWBIHB5WKYREGXMHMYV/
signature.asc (application/pgp-signature, 488 B)