Tox: Allow configuration via tool.tox in pyproject.toml

[pradyunsg]

pyproject.toml is a thing now. 🎉

It would be awesome if we could configure tox within pyproject.toml alone. This would allow for removal of a configuration file for a lot of projects.

[RonnyPfannschmidt]

i would like to note that this one is ____hard____ to get acceptably right

[obestwalter]

Hi @RonnyPfannschmidt, can you elaborate on that?

[pradyunsg]

If @obestwalter would want to do a cleanup of the configuration (removing deprecated options and so on), this would be a good opportunity to do so.

---

i would like to note that this one is hard to get acceptably right

Generated environments would be an (IMO interesting) challenge to translate into TOML. https://tox.readthedocs.io/en/latest/config.html#generating-environments-conditional-settings

Same goes for the exact format for the testenv declarations.

[RonnyPfannschmidt]

@obestwalter feature parity is tricky, since factors and generated environments are quite funky and hard to match to the new syntax

a interesting path for progression would be to support putting a tox.ini into a

[tool.tox]
legacy_config = """
old config file format
"""

as a starting point and then developing the ability to slowly switch simpler and more complex things over as the new format gets better tools

[pradyunsg]

a interesting path for progression would be to support putting a tox.ini into a

Hmmm... Or let both of the file formats co-exist, with one taking precedence over the other.

Then once feature parity is achieved, deprecate tox.ini and after a sufficiently long period, stop supporting it.

as the new format gets better tools

I'm not quite sure I understand what you mean by this?

[obestwalter]

@pradyunsg said:

Generated environments would be an (IMO interesting) challenge to translate into TOML. https://tox.readthedocs.io/en/latest/config.html#generating-environments-conditional-settings

Same goes for the exact format for the testenv declarations.

Yep, that's why I think it will not done by next week :) A way of getting the old format into toml first, therefore is a good first step, I think.

@RonnyPfannschmidt - your idea definitely looks like a good path to go forward right away, I would say. Wrapping the old ini as multiline string and calling it legacy makes it very clear right away, that atm this is just a hacky way to avoid another configuration file until real support is implemented.

[obestwalter]

@pradyunsg your idea would be to start implementing it right away and only support a limited feature set, if I understand correctly. I think both ways can go together: if you need advanced features and want everything in one file, use the legacy format and if you want to use proper toml syntax and only need a limited feature set, use the basic toml implementation.

[obestwalter]

@pradyunsg said:

If @obestwalter would want to do a cleanup of the configuration (removing deprecated options and so on), this would be a good opportunity to do so.

Definitely, but technically not really much is deprecated, so a lot would need to be re-implemented anyway, but going with good old pareto, we can cover 80% of user need already with 20% of the features (we only need to know which 20% :)).

[gaborbernat]

I can accept the legacy multi-line string in-lining of the config as a transition step, to get the ball rolling.

PS. Let's make it contain the format, e.g. have it as legacy_tox_ini.

[RonnyPfannschmidt]

@obestwalter some parts of the sections are likely easily transitioned

other parts would require a discussion - recall my ideas for mixins and inheritance as alternative for factors, it may be necessary to bring something like that back to life

[gaborbernat]

@RonnyPfannschmidt I've had some play around with this in my toxn playground, and I found inheritance to be really helpful.

[gaborbernat]

I've started adding pyproject.toml support, however, this requires a good thought of how this will interact with tox.ini and setup.cfg we support at the moment to be seamless. The preference I would say would be:

1. pyproject.toml if has tox sections and legacy_ini key content (warn if tox.ini exists that it will be ignored)
2. tox.ini
3. setup.cfg.

We need to add pyproject.toml to the automatic tox.ini discovery, method - e.g. when calling tox from within a subfolder things should still work. The user can manually specify the tox configuration file, so we need to look in this case at the extension to determine the parser.

[laike9m]

Any plan to add native implementation?

[pradyunsg]

Well, for starters, I think we should file a dedicated issue for discussion of that.

[gaborbernat]

I've tried in the past and the door is still open for tox 4 👍 generally the issue becomes that the toml format does not allow easy factorial expressions, so tends to be more verbose than the ini file.

[RonnyPfannschmidt]

it might be practical to steal ideas from nox there,
as it is using a python file for parametrization and the programming parts

if there was a mechanism for taking in tox envs/actions from libraries and&or local, possibly in subdir python bits, things should be simpler

imagine having

[tool.tox]
requires = ["tox>=4.0.0", "tox-use-pre-commit", "tox-siplified-pytest", "tox-make-sphinx"]
[tool.tox.simplified_pytest]
min_python_version = 3.5

and being done for practically all simple python packages

[RonnyPfannschmidt]

@gaborbernat i'd love to make a brainstorming on such a idea soonish (as such a development would remove most of my grievances with tox

[gaborbernat]

@RonnyPfannschmidt what you describe there is where I want to get with #1394 #1400

[asottile]

please don't use code syntax as configuration, it's impossible to reason about statically and rewrite reliably with a machine

[RonnyPfannschmidt]

Awesome

[gaborbernat]

please don't use code syntax as configuration, it's impossible to reason about statically and rewrite reliably with a machine

Yeah, definitely not. 😄 The idea of tox plugins defining environments themselves are good I think.

[RonnyPfannschmidt]

@asottile i do feel the need for some kind of code point for local plugins, as my general experience with the tox syntax is its freakishly limiting in many cases

[asottile]

@asottile i do feel the need for some kind of code point for local plugins, as my general experience with the tox syntax is its freakishly limiting in many cases

oh of course, that's part of planned tox 4.x -- I'm merely suggesting that this is not a good idea:

it might be practical to steal ideas from nox there,
as it is using a python file for parametrization and the programming parts

[RonnyPfannschmidt]

@asottile ideally all code parts are of course supplied by plugins and only configuration happens at the usage side

[asottile]

agreed :)

[ofek]

Any update?

[gaborbernat]

Not before tox 4, ETA end of year.