Install fails for Python 3.10 due to missing wheels and missing build tools

[Jason R. Coombs]

I feel like I've reported this issue before, but searching for "3.10" or "wheels" or "wheel" or even any bugs reported by myself, I can't find it. I want to make an update and additional plea, so I'm stating the core issue and then expanding on my request.

Attempting to install any project that depends on lxml is failing for Python 3.10 (https://github.com/jaraco/paradocx/runs/2994946668?check_suite_focus=true). As a result, I've been unable to test in CI any of the projects that depend on lxml, so I've disabled tests for Python 3.10 in those environments.

I know that a source distribution exists, but most of my projects rely on Github Actions whose environments don't include extension build support by default, and as a result, they're unable to build lxml from source without special handling.

The amount of effort and orchestration required to add build tools for each of macOS, Windows, and Linux for Python 3.10 only (or whatever the current pre-release of Python is) on each of dozens of projects, and then later to remove that orchestration once it's no longer needed is quite onerous, especially when one maintains hundreds of libraries, dozens of which rely on lxml. For example, do you know what incantations I could add to [this project skeleton](https://github.com/jaraco/skeleton) that would enable building of lxml from source, but only when wheels aren't available? I know I don't and I'm pretty sure anything that works would be messy.

I understand that the approach for projects like lxml is not to supply binary wheels until the version of Python is released as final, but that effectively means that projects relying on lxml need to disable testing on Python 3.10 until long after CPython 3.10 is released, missing the window to provide feedback on incompatibilities or address deprecation or other concerns early.

I'd really appreciate if this project could offer binary builds for pre-release versions of Python perhaps through one of the following mechanisms:

- Cut binary releases of the latest stable lxml, possibly with a post-release tag (or tags if binary compatibility changes).
- Make pre-release versions of the upcoming lxml release available in PyPI.
- Cut binary releases to a pre-release index such as https://m.devpi.net/, with the mirror pointing to PyPI, such that anyone wishing to opt in to the pre-releases could do so through this index.

All of these options would require a build and release approximately once per Python version, but would enable projects relying on lxml to easily opt in to these builds.

This last option is something that I could potentially do without any endorsement from the lxml project, but then it would only solve the problem for me and those who have visibility to my work and wish to trust my builds. If the lxml project had an official pre-release pipeline, that would have a far greater impact.

[Jason R. Coombs (jaraco)]

I found the previous report: https://bugs.launchpad.net/lxml/+bug/1929359

I still don't understand why it doesn't show up as one of my reported bugs or in any search.