Why does `tox -l` only show `python` when file is setup.cfg instead of tox.ini?

[Flimm]

Here's how I can reproduce the bug:

$ virtualenv -p python3 env
$ source env/bin/activate
$ pip install tox
$ ls
env
$ printf '[tox]\nenvlist = py26,py27,py33\n' > setup.cfg
$ cat setup.cfg
[tox]
envlist = py26,py27,py33
$ tox -l
python
$ mv setup.cfg tox.ini
$ tox -l
py26
py27
py33

What is going on? Why is tox -l behaving differently for identical content, the only difference between whether the configuration is loaded from setup.cfg or tox.ini?

Additional debug info:

$ pip list
Package    Version
---------- -------
pip        9.0.1
pluggy     0.4.0
py         1.4.34
setuptools 36.0.1
tox        2.7.0
virtualenv 15.1.0
wheel      0.29.0

I'm on macOS.

[obestwalter]

Hi @Flimm, what gave you the impression that it is supposed to work at all? AFAIK this was a hotly discussed topic, but never came to fruition: #297

Searching the docs a mention of some experimental feature for 2.4.0 comes up, but there are no docs, so I don't even know what it is supposed to be doing:

(experimental) New feature: When a search for a config file fails, tox tries loading setup.cfg with a section prefix of “tox”.

So I would argue that the actual bug is, that tox does not crash with a helpful error, if somebody tries to use setup.cfg for configuring tox.

And maybe we need to remove that experimental code, as it is not doing anything useful I can see.

[Flimm]

Several things give me the impression that tox is meant to read from setup.cfg.

1. It seems to read successfully from setup.cfg in some projects, for instance https://github.com/jazzband/sorl-thumbnail . I was trying to understand why it wouldn't on my machine, but did for Travis CI.

2. The changelog entry you pointed out says that "tox tries loading setup.cfg".

3. The verbose output of tox -lv says that it is trying to read setup.cfg:

$ tox -lv
using tox.ini: /home/flimm/git/flimm/bla/setup.cfg
using tox-2.7.0 from /home/flimm/git/flimm/bla/env/lib/python3.5/site-packages/tox/__init__.py
default environments:
python -> [no description]

Now that you point it out, documentation about setup.cfg is lacking.

I'm fine with removing support for setup.cfg, whatever you think is best.

[obestwalter]

Hey, thanks for summarizing. Sorry if I came over a bit snarky :)

I personally am perfectly happy with using only tox.ini for config, but as this being used in the wild already we can't just remove it without deprecating it first.

Let's wait if others have opinions ...

[gaborbernat]

As far as we can keep the tox configuration adhere to the ini specification I see no harm in actually having full setup.cfg support. At that point it is just a detail of from where we get the content to extract the project configuration from. I would actually be interested in making this work 100%.

[obestwalter]

@gaborbernat - please see this discussion: #297 - there is no agreement if this should work or if it would actually be better to leave it out.

[obestwalter]

Especially see this comment by @The-Compiler mentioning that it caused pain trying to support this in pytest and that they want to drop the support again: #297 (comment)

[obestwalter]

@Flimm - I am digging through the code atm and saw that at least your example should work already (only different).

The thing is that you need to use the section prefix 'tox' for all tox related sections (also for the global tox section), so if you do it that way it should work as expected:

setup.cfg:

[tox:tox]
envlist = py35,py36

tox -l:

py35
py37

If this weren't an experimental feature I would expect either the parsing to fail if I only have a [tox] section or have the global section work without the prefix and only expect the prefix for subsections.

[Flimm]

@obestwalter Thanks. If I use [tox:tox] in setup.cfg, it does indeed seem to work.

In this repo, tox seems to be able to pick up a [tox] section setup.cfg without the section prefix. I'm mystified as to why.

[obestwalter]

I was also mystified, so I tried it with that repo - it doesn't work. So this might be a regression - it might have worked at some point in the past, but I think namespaces are a honking great idea, so the way it works now is actually the right way to go.

[RonnyPfannschmidt]

wow, that prefix stuff is a scary mess - its a perfect example of when people should say no to a feature