Support for `abi3` Python packages with `abi3audit` checks

[jaimergp]

Proposal

Add support for abi3 Python packages to reduce the amount of artifacts produced for compatible projects (compliance checked with abi3audit).

Details

CPython has a "stable API" defined in PEP 384, which goes all the way back to Python 3.2. This allows compiled modules to run on newer Python versions than the one they were compiled against, as long as they only use the stable subset. Such packages are labeled as abi3.

conda-forge could package compatible packages like this, reducing the amount of artifacts (and build matrix entries) from V×P to P (V = Number of supported Python versions, P = Number of platforms).

In [this blog post] (recommended read!), authors reveal how this works in practice for PyPI, and how some packages opt-in to this label without actual compliance. To fix this issue, a tool abi3audit is developed, which can check for symbol usage and violations of the abi3 contract.

Implementation

If this sounds nice, we can think of how to implement it. Some ideas:

• Do it on conda-forge with some work. Hacky, but no new conda features needed:
  • Add checks or guidelines for staged-recipes to check for abi3 compatibility whenever possible.
  • Instrument conda-smithy with an abi3 mode, where Python in host is using the oldest supported Python, but run pins for >={oldest}.
  • Handle site-packages placement with symlinks, post-link scripts, patches in CPython default path.
• Add changes on conda and conda-build to support a new noarch variant (e.g. python-abi3) to handle this natively. This has the drawback of users needing to update to a newer conda to use this new package type.

Other notes

• Who wants to run (and publish?) an audit on conda-forge like the one in the blog post? 👀 Note some changes would be needed in abi3audit so it can scan non-abi3 objects.
• I am not sure about how well Windows is supported in this area.

References

• https://peps.python.org/pep-0384/
• https://blog.trailofbits.com/2022/11/15/python-wheels-abi-abi3audit/
• https://github.com/trailofbits/abi3audit

[jakirkham]

It seems like at a minimum would could add abi3 to the conda-forge Python matrix. Then add a migrator to add abi3 builds to packages and include an abi3audit run in test/commands. Admittedly this is adding one more thing to the the matrix, but it seems useful for people trying to get started with Python RCs (especially given the yearly release cycle of these)

[baszalmstra]

Another option would be to add a noarch python package together with a virtual package specifier (e.g. __linux). But this is very akward and the noarch package channel would grow with platform specific packages.

[jaimergp]

OS-specific noarch packages exist already today, so we are already in awkward territory :D

Splitting packages into different JSONs is decided only by conda-index, so we can technically instruct it to place the noarch + __linux packages in all linux-*/repodata.json files (not saying that we should, but we can) 😂 But then we would be breaking the assumption that all packages in a given JSON have the same subdir.

[jaimergp]

Some feedstocks are already looking into this. See: https://github.com/conda-forge/qiskit-terra-feedstock/pull/41

[jaimergp]

And for those watching this space, check https://github.com/conda-forge/python-feedstock/pull/669.

[wshanks]

It would be nice if abi3audit supported conda packages (I know there is an upstream issue linked above already). In my testing for now, I run it with explicit paths to the .so files of the installed package to check.