Better support CI python version specification strings

[avylove]

I assume this has been requested before, but I couldn't find an issue for it. So apologies if this is a duplicate.

What

tox -e py3.10 should be equivalent to tox -e py310

Why

This would simplify a lot of CI configurations.

A lot of CI configurations require extra config or logic to match Python versions to their tox equivalent. This is done in a number of ways (plugins, character stripping, environment variables, etc) depending of the CI framework and who is implementing it. It would be much easier if tox considered the dotted version equivalent to the undotted version.

[gaborbernat]

No one requested this feature yet.

I assume you mean without the py prefix, because if you add the py prefix would not generalize well to pypy. In case of Github Actions pypy is expressed as https://github.com/actions/setup-python#available-versions-of-python pypy-3.6-v7.3.3. Similar with beta you'd get pypy-3.6-v7.3.3. Sadly tox uses - as a factor separator, so handling forms such as pypy-3.6-v7.3.3 would not be trivial. That being said I'm not saying no to this, but needs deeper thought and someone willing to do the heavy lifting: implementation with tests. We should also collect and see all major CI platforms python version spec format, so we can see what would be most universally acceptable.

[avylove]

I think it's fine to leave the py prefix. It's much easier to prepend than it is to remove a character.

For example, in GitHub actions, you might set your Python version in a matrix as

    `python-version: 3.9`

Then in your job, you'd install Python

    with:
      python-version: ${{ matrix.python-version }}

If tox treated py3.9 and py39 as equivalents, you could just do one of these

    env:
      TOXENV: py${{ matrix.python-version }}
    run: tox

OR

    run: tox -e py${{ matrix.python-version }}

[gaborbernat]

Yeah I get that part, but you're not addressing the elephant in the room I've raised, how would you combine py with pypy version specifiers, or just pypy in general?

[avylove]

Oh sorry, I missed the part about pypy. It would be good to include it, but I think just accepting the dots would be a step in the right direction. It's a bit unfortunate GH decide to use a dash in pypy names. I do test pypy on many projects, so I'd still have to do something there, but it would still save a ton of work.

The way I do this today is to define both python-version and toxenv for every version. You can account for pypy in GH Actions by allowing a TOXENV override.

    env:
      TOXENV: ${{ matrix.toxenv || 'py'${{ matrix.python-version }} }}

This is still better than having to define both for every test.

In summary, I'm asking for py3.9 to be equivalent to py39. pypy-3.7 equivalent to pypy37 is also useful, but a different ask. While these are related and fall under the bucket of more flexible default environment names, they are not dependent on each other and don't need to be done at the same time.

[gaborbernat]

In summary, I'm asking for py3.9 to be equivalent to py39. pypy-3.7 equivalent to pypy37 is also useful, but a different ask.

I strongly disagree. Sorry, but we don't shoehorn in one specific use case hacks. If we add a feature needs to generalize to cross python flavors from day 1. Furthermore it cannot be one CI env specific. It needs to handle at least Github, Circle CI, Azure Pipelines, Travis and AppVeyor. I'd like to see a comparision of their Python spec to start out flashing out a design.

[avylove]

I see where you're coming from, but making py3.9 equivalent to py39 is not specific to Python flavors or a specific CI. It would be generally useful. For example, it would mean pypy3.7 would be equivalent to pypy37.

That said, a more general use case would be welcomed.

I think the general use case would need a config option to disable/enable the option, and depending on how close the different CI frameworks are, possibly a flavor selector. Then it's essentially pattern matching using regexes. I think you're right, starting with the CI specs is a good first step.

[gaborbernat]

I see where you're coming from, but making py3.9 equivalent to py39 is not specific to Python flavors or a specific CI. It would be generally useful. For example, it would mean pypy3.7 would be equivalent to pypy37.

You need to think past the trivial case and see how such change would impact the more extreme. If we allow users to pass any Github approved spec, we need to handle not just 3.9 or py3.9 but also the form of pypy-3.6-v7.3.3 or 3.10.0-beta.4. Also maybe we don't need this part of core... we could also expose a plugin endpoint where a plugin can map CLI version specs to internal tox specs. In this case a tox-github-ci plugin can handle github, a tox-azure-ci can do for Azure and so on.

[gaborbernat]

This has been done with 4.0 so should work.