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

[rameshreddy-adutla]

This happens when tool execution results are lost from chat memory before the next LLM call. The OpenAI API requires every tool_calls message to be followed by a tool message for each tool_call_id.

Root cause: Chat memory window is too small, so older messages (including tool responses) get evicted while the assistant message with tool_calls is still in context.

Fix — increase chat memory window:

ChatMemoryProvider chatMemoryProvider = chatMemoryId ->
    MessageWindowChatMemory.builder()
        .id(chatMemoryId)
        .maxMessages(50)  // increase from default 10
        .build();

Why 50? Each tool call adds at least 2 messages (assistant tool_calls + tool response). If your tools depend on each other (chained calls), a single user request can produce 10+ messages. With maxMessages(10), the window evicts tool responses while keeping the assistant message that references them.

Alternative — use TokenWindowChatMemory for more precise control:

ChatMemoryProvider chatMemoryProvider = chatMemoryId ->
    TokenWindowChatMemory.builder()
        .id(chatMemoryId)
        .maxTokens(4000)
        .tokenizer(new OpenAiTokenizer())
        .build();

This is a known limitation of windowed memory with tool-calling agents. The key insight is: never evict a tool response without also evicting the tool_calls message that triggered it.