Skip to content

Instantly share code, notes, and snippets.

@EwoutH
Created October 17, 2022 15:58
Show Gist options
  • Save EwoutH/b98ff30453911d5b55fd96956f7661fd to your computer and use it in GitHub Desktop.
Save EwoutH/b98ff30453911d5b55fd96956f7661fd to your computer and use it in GitHub Desktop.
Introduce system to recognize, manage and install non-ABI-stable Python wheels (created with alpha/beta versions of Python)

Problem

Wheels are extremely important for the Python ecosystem, and especially the scientific subsection. Newer Python versions offer many benefits, like new features and faster performance. On the release of a new Python version, for many packages wheels are unfortunately often not immediately available for that version.

This is a problem with many aspects, and in this feature request a system is proposed to partly but significant improve this situations.

The Python annual release cycle, as described in PEP 602, knows 3 phases. In the Alpha phase new features are added and bugs are fixed, during 7 months. The 3-month Beta phase allows for bug fixes. The 2-month release candidate phase is not clearly described in PEP 602, but practically only essential bugs and security issues are fixed. Historically, it also starts the ABI-stable phase for that minor Python version (Python 3.10.0rc1 | 3.11.0rc1.

This 2-month phase is where currently the wheel-building race starts for many projects. And while for a single project two months should be more than enough, many projects depend on many other projects. On the scientific stack, for example, Cython needs to come in first, then NumPy, then SciPy and Pandas, then scikit-learn and statsmodels. And if you projects depends on one of the latter, this two-month window gets really short.

In this window, not only wheels need to be successfully build for the new Python version, but also need to be included in a tagged release. For many projects, this means backporting to a maintenance branch and tagging a new patch release.

Since amending PEP 602 would be a major undertaking and have many side-effects on the ecosystem, this feature request proposes a system for managing wheels on PyPI created with non-ABI-stable Python versions.

Solution

TODO

Alternatives

Amending PEP 602 would be a major undertaking and have many side-effects on the ecosystem, so is not preferable.

Apart from extending the wheel-distribution period, another angle could be a speedup in getting wheels on PyPI. One option for this could be allowing (periodically) generated wheels from a development branch. This way dependent projects don't have to wait for a backport and stable release to be tagged. This solution could work in conjunction with the proposed solution in this feature request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment