A couple of quick points:
* You want to focus on setuptools rather than distutils. Setuptools extends distutils with recent packaging developments, distutils is essentially just core Python legacy support these days. * Wheels (built binaries) are typically tagged as manylinux using the auditwheel project (https://github.com/pypa/auditwheel) although you are in theory allowed to manually apply the manylinux tag if you can verify that your wheel conforms to the requirements listed in the relevant manylinux spec/PEP. * By default, binaries built on linux are tagged as "linux" which means "no guarantee that this can be run on any machine other than the one it was built on". Such wheels cannot be uploaded to PyPI. * Pip includes rules that let it determine what tags are suitable for installation on this machine. The details are in https://packaging.python.org/specifications/platform-compatibility-tags/ (and that link references PEP 425 as well as the manylinux PEPs for the details).
Whether manylinux is relevant for AIX is something you'll have to decide. Ultimately it depends on how well the default rules in PEP 425 manage to ensure that binaries are interoperable, which in turn probably depends on how Python typically gets built on AIX, and how compatible dynamically linked system libraries are across machines.
On Tue, 13 Aug 2019 at 15:56, Michael email@example.com wrote:
On 06/08/2019 09:15, Michael wrote: OK - been about a week - so, before I forget everything a list-ping...
Quick summary: re: manylinix1 approach: read several docs and checked CPython - please tell me if/where I am missing something.
- I do not have a Linux system to look at separately, maybe I must look for a system (I can trash by accident)
- the manylinux support is external to CPython (Lib/distutils)
- how does pip/dist-utils interpet the "label" that is applied to a package
- is the label applied by the CPython distutils package, or is that package "overwritten" by the distutils part of pip? This concerns whether I would need to write a PR for CPython, or for distutils (aka, who is the 'owner' of distutils
I suppose there is more - but I hope to get some level of synchronization before getting too far along.
Thanks for your assistance!
On 03/08/2019 12:16, Ronald Oussoren via Distutils-SIG wrote:
On 01/08/2019 11:07, Michael wrote:
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())
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())
What I forgot to mention - there is likely incompatibilities when different compilers are used. This is definetly the case when source files need a C compiler - and I fear that the different run-time environments of gcc versus xlc (which does not need/link to glibc).
So, how does, e.g., macos account for differences between clang and gcc compiled executables and modules. Or are both compilers "gnu" oriented?
OK - after reading PEP513 (and PEP571) I see that the "approach" is different. These PEPs came up with a 'white-list' of acceptable shared libraries - while the AIX approach has focused on "new OS levels support old OS levels".
In any case - I see this as a "format" for a wheel 'label'
where, I assume cp27 stands for CPython-2.7 - so the "front-end": PKG-VERSION-cp27-cp27m- is 'provided' and what I need to replace is the 'tail' manylinux1_x86_64.whl
So, since my approach is NOT to have a list of acceptable libraries - I guess I would start with something like:
PKG-VERSION-cp37-cp37m-aix_6100_07-32b.whl and PKG-VERSION-cp37-cp37md-aix_6100_07-32b.whl
++++ PEP571 mentions "try:\n import _manylinux\n..."
As I look around I get the impression that this is a module that the manylinux docker image is 'inserting'.
The deeper I look, the less I see in this approach. The "common-ground" is that they also state the 'heart' of having portable code is having access to an "old" machine - and providing that via docker.
++++ What I am looking to accomplish is to have a way to "accept" a package labeled
PKG-VERSION-cp37-cp37md-aix_6100_09-32b.whl if the label "I" would generate is:
PKG-VERSION-cp37-cp37md-aix_6100_10-32b.whl or PKG-VERSION-cp37-cp37md-aix_7100_07-32b.whl
but not accept
PKG-VERSION-cp37-cp37md-aix_6100_07-32b.whl or PKG-VERSION-cp37-cp37m-aix_6100_09-32b.whl or PKG-VERSION-cp37-cp37md-aix_6100_09-64b.whl
This means the "mdu" characters need to match, also the cpXY - and the "32|64"b and the aix_XY00_TL needs to be lower, or equal to the 'running' system.
So, what am I missing - and where should this (plus anything else) be inserted?
-- Distutils-SIG mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://firstname.lastname@example.org/message/Q4PGP...
-- Distutils-SIG mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://email@example.com/message/5JR7A...