Introduce an additional configuration file format?

[obestwalter]

I want to open the discussion for adding a second possibility of configuring tox additionally to the tox.ini format. If we would do this, we could freeze the state of what tox.ini can and can't to to the state of what it is now and support it in that maintenance mode for a long time / infinitely.

This might be a very bad idea and could very possibly be just a knee jerk reaction to my not so pleasant experiences trying to fix #595 but I wanted to at least hear what others feel about this.

[gaborbernat]

I would prefer sticking to the current version, especially as many tools already integrate with the current configuration file.

[obestwalter]

The old format would likely be supported for a very long time, but I am a bit weary adding new features to the old config format. It is really quite convoluted already. At the very least the whole config related code would need a complete overhaul to keep it maintainable.

Also: what do you mean by integrating? They do things with the actual tox.ini?

[gaborbernat]

I mean e.g. pytest accepts configuration data also from tox.ini. Which means they actually parse it; and there are other projects out there who do similarly. I'm aware it's really convoluted, as I already had luck dealing with it; but would still prefer/do the complete refactor than creating a new configuration file.

[RonnyPfannschmidt]

@obestwalter a good number of tools like flake8 for example hijacked tox.ini, even pytest did, but for pytest we created a way that can work

in general both tox and pytest should take a look at pyproject.toml ^^

[obestwalter]

I mean e.g. pytest accepts configuration data also from tox.ini.

I see what you mean, this would still continue to work though. And if people would want to switch to the new format we either might be able to make it work just like that (if it would be TOML like @vlaci and @RonnyPfannschmidt suggested) that would be trivial. The guest project could just add another config file as source or they just have to move their configuration to setup.cfg or the orginal config file.

Anyway this is just dreaming a bit, because before this would be possible the related code needs to be refactored to prepare for that anyway and the refactoring might even already ease some of the maintenance pains.

[RonnyPfannschmidt]

personally i think starting to explore toml may open up a way to remove a lot of my pain points with the project

[gaborbernat]

agreed, let's see then what we can do with TOML

[obestwalter]

How about Python? Just learned about nox: http://nox.readthedocs.io/en/latest/ - started recently by @jonparrott.

[theacodes]

I recently did a quick talk about Nox at PuPPy - slides are here for those interested.

Fwiw - I think that there's room for both. I always considered Nox as an advanced tool and still use tox for several of my own projects. I think there's strength in both approaches - I don't think that tox needs to become Nox (or vice versa) any more than I think Flask needs to become Django.

[theacodes]

That said literally anything but ini files. :)

[merwok]

One can also imagine tox devs publishing a small module to support parsing tox.ini or tox.toml into a structured form, and pytest / flake8 / coverage and others could rely on that lib for parsing.

[obestwalter]

One can also imagine tox devs publishing a small module to support parsing tox.ini or tox.toml into a structured form

That sounds interesting, but I don't think it would solve the problem this issue is trying to address. For me the main problem is the parsing. It grew more and more complex when functionality was added and I think it was never really refactored to make it simpler. So another approach would be to invest some time to refactor the parsing code.

[pradyunsg]

Being able to use the tool.tox namespace within pyproject.toml for tox configuration would be neat. :)

[obestwalter]

Hi @pradyunsg - do you mean to have a "traditional" tox.ini being part of a pyproject.toml?

[pradyunsg]

Yep.

[obestwalter]

Sounds like a good idea. Would you like to open an issue for that?

[obestwalter]

So it looks like it definitely should be TOML.

[pradyunsg]

Would you like to open an issue for that?

#814

So it looks like it definitely should be TOML.

Indeed. I guess that means this issue can be closed.

[RonnyPfannschmidt]

simply inlining tox.ini in a pyproject.tmp feels a bit bad

[obestwalter]

I know, this is why it should be toml, because then we either don't have to do it at all, if toml support comes first or only have to do it until toml support is implemented.

[obestwalter]

Closing this as it looks like the decision has been made and now it is only a question of how to implement it, while retaining backwards compatibility. Issue for that is here: #814