Automatically add new versions upon their release

[mirekdlugosz]

When new Python patch version is released, it can be added to pyenv by copying python-build file for previous patch version. Oftentimes all you have to do is changing version number and checksums.

I would like to start a discussion: how much of version maintenance could be automated? How much should be automated? What is preventing us from achieving desired level of automation?

I imagine GitHub Action bot that periodically checks relevant RSS feeds for latest version announcements. If new version is available, it prepares change in repository and submits it as a PR. It could even merge the PR automatically if pipeline is green, and tag a new release.

The greatest benefit would be much quicker delivery of new upstream releases - possibly within hour from announcement. That will also allow maintainers to focus on situations where actual human-level attention is needed.

The general problem of "pyenv users have to wait long time before they can use newest upstream release" has been discussed previously in #1771 and #2313. These threads mention weeks-long waiting time - situation seems to have been greatly improved since then.

The road to full automation is long, but can be done step-by-step:

1. Only generate files automatically - checking for new versions and creating PRs is done manually
2. Check for new versions and generate files automatically, but create PRs manually
3. Check, generate files and create PRs automatically from Github Actions bot
4. Focus only on CPython patch releases first. Preview releases and new minor versions are done manually. PyPy, conda and other distributions are done manually.
5. Extend automation for things in step 4, one at a time
6. Merge PRs and tag new releases from GitHub Actions, too

@anton-petrov @chrahunt @joshfriend @native-api

[mirekdlugosz]

I have implemented quick-and-dirty proof-of-concept script for step 1 in my fork. It also allowed me to start better understanding the problem space. It prompted questions like:

What is the current approach to SSL and readline versions? Just "take the newest one available at the time of Python version release", or is it more involved?

[native-api]

We have this in the plans, there are even completed scraper scripts for a number of flavors in plugins/python-build/scripts.

The idea is to automatically generate PRs based on the changes they make, and merge them automatically, too, if the checks succeed.

[mirekdlugosz]

Is this effort tracked somewhere? How could one contribute?

[native-api]

It's not but that's easy to fix.
It's supposed to be a single PR to complete, so there isn't much to track.

[native-api]

#2690