dash vs. comma format in bracketed section names in .ini is either broken or needs better docs

[zzzeek]

Issue

in the docs, we see that there's a syntax we can use like this:

"Both enumerations ({1,2,3}) and numerical ranges ({1-3}) are supported, and can be mixed together:"
[tox]
env_list = py3{8-10, 11, 13-14}

wow! i never knew that. the dash part.

But that's in the env_list. Where is the specification for this format as used elsewhere? we see an example like this:

[testenv]
deps =
    py311,py310: urllib3
    py{311,310}-sqlite: mock

Can we use the dash format there too? Nope. The bug is, that every {} syntax should work everywhere (preferred!) or the docs need to really talk about what's allowed where and be very specific what's going on.

Below is an example of these syntaxes. It illustrates that while we can use py{39,310,311,312,313} just fine in a key, we cannot use py{39-313} - gets ignored silently. As a bonus, someone today also tried to use the {} nesting syntax that works for {env:} with the environment name tags, that doesnt work either.

Ive been listing out py{39,310,311} type things for many years, and it's tedious. It seems like tox by now should have gained some more flexibility with these things. Is this....better in TOML format ? is .ini the old way replaced by TOML ?

Example:

[tox]
envlist = py

[extras1]
deps=
    greenlet

[extras2]
deps=
    typing-extensions

[extras3]
deps=
    requests


[testenv]

deps=
     # a syntax that works.
    somespec-py{38,39,310,311,312,313,314}: {[extras1]deps}

     # can we use the dash syntax instead of listing out every version?
     # nope
    somespec-py{38-314}: {[extras2]deps}

     # can we nest inside these things?  nope, this syntax is not accepted
     # somespec-{py{312,313},otherspec}: {[extras3]deps}

allowlist_externals =
    sh

commands=
    sh -c echo  "hello world"

run this as:

$ tox -re somespec-py313 --notest

only greenlet gets installed. typing-extensions does not:

[classic@framework tmp]$ tox -re somespec-py313 --notest
somespec-py313: remove tox env folder /home/classic/tmp/.tox/somespec-py313
somespec-py313: install_deps> python -I -m pip install greenlet
  somespec-py313: OK (0.78 seconds)
  congratulations :) (0.81 seconds)

[gaborbernat]

I'd say should work, if it doesn't you're free to submit both documentation and bugfix PRs, thanks! I generally moved towards TOML config, so have low interest in fixing the ini format (it's really error prone).

[zzzeek]

I generally moved towards TOML config, so have low interest in fixing the ini format (it's really error prone).

ah, and you are the tox maintainer, right? this could potentially mean I'm highly motivated to get off this syntax...

however

the whole env list concept is local to the .ini file? How would I write my configuration above in toml format? I dont see anything in the documentation about how any of this is achieved in toml . If I have to write out 58 separate environments in toml that's not going to work.

[gaborbernat]

We don't have that yet supported in TOML, but PRs welcome 🤔 Similar how TOML has it's own substitution logic https://tox.wiki/en/4.30.2/config.html#toml-only, we'd want also something similar for generative environments. Someone needs to brainstorm proposals on how to and then implement it 🤔 PRs welcome in that direction too 😄

[zzzeek]

So tox admirably introduced a new TOML format that supersedes the .ini format, but there's no concrete plan for porting along a major area of functionality from the old system, that remains absent from the new system. Issues with this same area of functionality in the .ini format are similarly not targeted for active maintenance in the absence of new contributions.

From my perspective, this puts tox in a precarious position because this implies the project has more or less declared the generative environment feature as legacy, shrinking the featureset of tox significantly, unless new contributions come in.

I dont have a problem with any of this, but I'm just pointing out that this is effectively shrinking tox's feature scope for the time being (and that is OK! I am not asking for anything).

Feel free to close this as wontfix unless you want to leave it open for someone to look at.

[gaborbernat]

I just want to add that we have no plans to remove INI support, so the support is there, just we'd rather focus new efforts on TOML rather than INI. While INI is very flexible it also means that is also very brittle that bite us many times in the past.