Allow open ended generative option for python interpreter

[ssbarnea]

What's the problem this feature will solve?

The main goal is to reduce the need to update the list of python test environments when a new version of python is released.

Current situation requires updating at least env_list to include add new versions of python. Also, minimal version of python needs to be manually updated and kept in sync with requires-python.

Describe the solution you'd like

It would be very useful to have some kind of generative options that would eliminate this manual updates, maybe something like:

• py{3.9-} which would expand to all known/available interpreters starting with 3.9. Is an extension of currently supported py3{9-13} as it was added by feat(config): Allow ranges in envlist #3503
• {supported_pythons} which would even remove the need to set minimal one, which would be taken from requires-python`

Alternative Solutions

Additional context

We might want to allow plugins to change the behavior because while user might not have python3.14 installed on his system, tox-uv plugin might be able to install it on demand.

It would also be useful to recommend a consistent way to name tox environments as currently I seen a wide range of names:

• py310 - probably most popular, also having the advantage of being able to use py when you just want to use your default version when running tests.
• 3.10 - just numeric, currently used by tox, tox-uv,.. downside is there is no way to declare an expansion that refers to all python versions but no other environments. To clarify, imagine that I want to declare an environment variable only for unittest regardless the python version. How can I do this?
• other combinations

Maybe I should add that last part into a separate ticket? If we agree on a recommended naming, it would be much easier to document it and seek to make the tox usage more consistent between projects, with less surprises regarding how environment names are named. Because tox magically allow random names, I ended with some accidents more than once, where I did run tox -e <something> that was not really supported but it did run and gave me a false positive.

[gaborbernat]

The main goal is to reduce the need to update the list of python test environments when a new version of python is released.

You need to update the CI anyway, so it's not like saving that much, is it? Not to mention, that new version might break you so you don't want to include it without a PR 🤔

[ssbarnea]

In fact I already two different CI implementations that use tox that can enable new python versions by default once they become available. One is at https://github.com/coactions/dynamic-matrix -- this GH action does have a max_python argument which can be updated. If user wants to prevent use of newer python version, they can override the default.

With dependabot/renovate/similar users will be notified when a newer version of the action is released, and that will enable new python versions testing on CI. The tricky bit is that this does not update tox's env_list, so a user doing tox -lav will not see them. If that PR does break is ok, at least they will know it, is not that it will be merged automatically.

Mainly I raised this because I want to enable tox itself to do this "dynamic" version range expansion.

If you have other suggestions?

[gaborbernat]

Nothing at the moment, I'm just raising why I'm not sure this is a good idea. Could it be a plugin until we figure out what's a good approach to this?

[webknjaz]

FTR, Hynek's automations parse the matrix out of the Trove classifiers.