Goal - using wheels rather than RPM and/or installp formats for distributing binary modules Why bother? One reason (there are likely more) - using wheels means packages/modules can be loaded in a virtualenv rather than require they are first loaded in the system environment using installp/rpm/yum (with root authority). This alone has been reason enough for me to do the research. Introduction The use of pip and wheels is commonplace in the worlds of Linux, macOS and Windows. Not so for AIX. Not because it couldn't be commonplace. The current situation for AIX is comparable to the initial issue Linux was facing when PEP513 was written: "Currently, distribution of binary Python extensions for Windows and OS X is straightforward. ... For Linux, the situation is much more delicate. ... Build tools using PEP 425 platform tags [3] do not track information about the particular Linux distribution or installed system libraries, and instead assign all wheels the too-vague linux_i686 or linux_x86_64 tags. Because of this ambiguity, ..." The root cause for the *ambiguity* that Linux systems had is not the ambiguity that AIX faces. AIX has provided a consistent way to "tag" it's runtime environment since at least 2007 (AIX 5.3 TL7). Since that time IBM AIX has also *guaranteed* binary compatibility for migration of applications from old to new OS levels. I would like to see these tags added - at a minimum that they can be retrieved by something such as sysconfig.get_var('AIC_BLD_TAG'). It would be "nice" to see sysconfig.get_platform() updated to include these values from the running system. Further, while pip related tools can add the "bitness" to the platform tags I would like to see something added to the AIX get_platform() tag (b32, ppc, aix32), (b64, ppc64, aix64) for 32 and 64 bit operations, respectively - as that is a "running" environment attribute. Open to other ideas on what the bitness tag should be. IMHO - anything is better than nothing. Maybe this could be considered a bug rather than as a new feature. Thank you for your feedback. Michael