Packaging and Python for AIX

AIX is not the best known Python platform. But AIX is the platform I know best.

  • For several years, as aixtools ( I have been building and packaging Python for AIX. For modules/packages, generally I leave that to users (as do other packagers of Python for AIX (Michael Perzl, BULL Freeware, IBM AIX Toolbox) to use pip, if they can, and download source packages and “install”).

  • For the packages that do get pre-built - they need to be downloaded from my site, Perzl, Bull, or IBM - and they are pre-wrapped as an RPM (the others) or as installp (mine). This is not the Python way:
    a) installp/rpm packaging forces both root (su, rbac, or sudo) access and only to a system level installation;
    b) users wishing to use virtualenv these pre-wrapped packages must be installed system level first (as they cannot install into a virtualenv - locations are (for all practicable purposes) hard-coded.

  • I have experimented with devpi-server - enough to learn that wheels can be built and installed - but the current support for tagging is so ambigious (much the same ambiguity Linux faced before manylinux1 was introduced).

  • I have a good idea of what is needed - but I have learned that just doing something and thinking everyone will be amazed (that noone had done it before) leads to (my) disappointment (:stuck_out_tongue: at me).

  • So, I hope to find support - enough to be able to move forward - for bringing packaing for Python for AIX into the mainstream aka common-practice.

Thanks for your time to read, think and comment!


2 Likes seems to be a dead link?

Thanks. Forgot the “index.php” piece. Have corrected the link.

The site just won’t load for me. Has anyone else had better luck with that?

The site just won’t load for me. Has anyone else had better luck with that?

Yesterday, my ISP changed, so did the IP address.

If you manually set to (e.g., in
/etc/hosts or \windows\system32\drivers\etc\hosts - the site should load.

When it rains, it pours.

Sadly, my domain register, who also manages my nameserver for aixtools -
is not available. Seems a router between them and myself is sending
packets into blackhole. (sigh2)


update: 18 hours later. Still no contact with domain registrar. Am very very worried!

I was able to access the site with your instructions but there was nothing of interest to me. I was just trying to find documentation that would help me validate the AIX support PR against wheel.

Back again - here. A short summary on how this has moved on, what I have tested, and what I am waiting for.

In August I submitted a PR in both pypa/pip and pypa/wheel, and I also submitted on for Cpython. All of these were to do just one thing: provide a platform tag for AIX that would permit effective bdist labeling.

The PRs for pip and wheel have been closed - waiting for action to be taken by CPython. So, currently, waiting for the proposed platform tag to be reviewed, and I hope eventually, merged.

With the patch in CPython pypa/pip plus wheel module I can create bdist packages that include compiled code (e.g., by a C compiler). As is, .whl files are loadable when the tag the running system makes is identical to the tag generated by the build system. If I take these files - and merely rename them so that the tags are again equal - the bdist packaged modules install and operate as expected.

FYI: modules built on AIX 5.3 and 6.1 run on AIX 7.1 and 7.2.

Once what the platform_tag looks like is settled I expect to have a few questions re: how packages are searched for on pypi. My best guess atm is that the client is generating a lot of names that are searched for as an exact match.

When the time comes I’ll appreciate assistance with identifying the code that searches pypi for a potential bdist package.

Thank you for your time.


I haven’t looked at any of the patches, but it’s not required for CPython to support a platform in order for wheels to include it in their tags. (CPython has no inherent support for manylinux, for example.)

Hi. Thanks for the comment.

Back in August I asked someone how to get started and the
recommendation was to read PEP425 and think about a proposal for a
platform tag that suffice. That took awhile to understand - as
everyone assumed it would be more like manylinux, and a new PEP,
than like macos - where there is less diversity - likely as there
is only one source.

So, while I recognized that it was not literally a per-requisite - the feedback
I received gave me the impression I should look for
acceptance in “changing” the historical tag. The other plus was
that I already saw that pip and wheel “just worked” for wheels
based on equality.

And so my intent/goal is that the patch for Python-3.9 is 95%+
the same code that would be used in pypa/tools - as it is via
these tools that the PEP425 support moves into earlier releases.

I know, rather expect, this will be a long process to get it to
where I hope it will be - but even having wheels at equality only
is a very big step forward in providing a better Python eco-system
for Python users. You do not need to be root to install modules,
neither are you required to have access to a compiler for modules
that are not pure python.

I am neither a Python developer nor user. I do get requests for
assistance from admins who want to use Python but run into
continual packaging issues. As a platform specialist I am hoping
to help people in need. Sounds noble - but I also enjoy learning -
and this has come with a lot of that :p.