native pyproject.toml config

[gaborbernat]

This is a ticket to track and implement a native pyproject.toml configuration. Will update with the proposed plan and format.

Core goals:

• explicitly inheritance based (a lot of substitution at the moment is used to replicate inheritance),
• substitution able,
• reasonably familiar (e.g. share most concepts with ini format),
• succinct (some form of factors needs to have).

We'll use this opportunity to rename some keys (e.g. skipsdist should be skip_packaging, etc).

[obestwalter]

Learning from the old format, I would add:

• easy to debug (good visualization of the settings - `--showconfig`` 2.0)
• conservative error handling (err on the side of crashing early with a helpful error, rather than being too allowing for "creative" uses)

[obestwalter]

... and most importantly: a clear, versioned specification that can then evolve as we for sure won't get it right at first try :)

[obestwalter]

I think, It would be great if we could organize a sprint around this whole topic at some point this year.

[gaborbernat]

Well, most importantly we need someone try to tackle this and implement it. Personally, in my priority queue, this is quite low. I've tackled it inside https://github.com/gaborbernat/toxn/blob/master/pyproject.toml#L5 only to prove it's quite hard to get this right. I'll only have some bandwidth for this after the #1102, #998 and #338. I also want to first split up configuration module from a mega file to sub-modules.

GitHub

gaborbernat/toxn

toxn aims to automate and standardize testing in Python - next generation tox - gaborbernat/toxn

[obestwalter]

That's exactly why I think a sprint with a few more people might be a good way to get this off the ground. Maybe around a conference where a few of as will go anyway - e.g. EuroPython.

[gaborbernat]

I don't consider this a good candidate for a sprint. That creates an artificial deadline (e.g. end of sprint). Instead, we should probably propose each and every one of us our own proposal and iterate on that until we find something that can do at least what the ini does at the moment. With toxn I had to start over a few times just because halfway through I figured well this path makes feature x/y really hard to support/implement.

[ionelmc]

Why not a tox.toml? pyproject.toml is going to be a mess (just like setup.cfg was when people decided to make tools that rewrite/change stuff in it).

[obestwalter]

@gaborbernat

That creates an artificial deadline (e.g. end of sprint).

Only in your head :) A sprint would in my eyes be a good way to make progress and share state, but in no way a deadline. Especially if you explored that area already with your toxn fork, you could share what you learned and we could take it from there.

@ionelmc

Why not a tox.toml?

That would be simply the [tool.tox] part of pyproject.toml, so that comes pretty much free with it. As a user I would definitely also want the possibility to configure tox still in an extra file if it is more involved.

pyproject.toml is going to be a mess (just like setup.cfg was when people decided to make tools that rewrite/change stuff in it).

Why do you think that? I might be a bit naive because I am really not that deep in the whole packaging topic, but I am pretty hopeful that this time around we'll do things better.

[gaborbernat]

I don't think it's going to be a mess. But it definitely can be hard to maintain once many things will try to use it. E.g. a complex tox + towncrier + black config can easily make pyproject.toml 200+ lines. I think there's no reason to limit ourselves to pyproject.toml only. I would say let's have by default tox section inside pyproject.toml, but fallback to tox.toml who want to separate it out.

[ionelmc]

Why do you think that? I might be a bit naive because I am really not that deep in the whole packaging topic, but I am pretty hopeful that this time around we'll do things better.

Well ... how to put it ... I've looked at https://github.com/gaborbernat/toxn/blob/master/pyproject.toml#L5 and I thought "well I don't want to write all those ridiculously long section names, I'd already be at my wits' end after all those quotes and brackets".

The second thing is that there will inevitably be broken tools that try to modify pyproject.toml - eg: bumpversion rewrites setup.cfg (if you're naive enough to use that - I was) but with slightly different values for the other sections.

From my perspective the only benefit of toml is that tox will get more features.

To give a bit more perspective, pyproject.toml is the new hotness but also these were too the new hotness some years ago:

• setuptools - turned out to be a huge pile of buggy monkeypatching
• distribute - turned out to be a huge pile of evil monkeypatching, but with different bugs - remember those projects that messed up your python installation cause they bundled a distribute_setup.py that tried to replace installed setuptools with distribute? i do
• disutils2 - an abandoned reimplementation of distutils

What I'm getting at here: ignore the PEP518/pyproject.toml bandwagon - just think about a new configuration system for tox.

GitHub

gaborbernat/toxn

toxn aims to automate and standardize testing in Python - next generation tox - gaborbernat/toxn

[gaborbernat]

I'm a bit conflicted here now though, I don't think we can come up with anything as succinct as our current ini format. So if writing brackets and quotes is going to become a problem (which very easily could be, I found myself to be a bit awkward when I've created toxn), I don't think there's much benefit from moving off the ini format.

[ionelmc]

Hmmm, can you elaborate a bit more on this goal:

explicitly inheritance based (a lot of substitution at the moment is used to replicate inheritance)

[ChihweiLHBird]

Is the work related to this issue still in schedule?

[jugmac00]

The current focus is on getting tox 4 ready for a final release. Just last week the final alpha was released.

This feature was scheduled for 4.1. Once we get tox 4 out, there will be quite a transition period and possibly quite some edge cases coming up which need attention.

That said - let's see what @gaborbernat has to add.

[gaborbernat]

Mostly what @jugmac00 said. The design of the tox 4 is made to allow this without too much of heavy-lift but I'd not pull myself into this when trying to make tox 4 actually come out the door. But would like to follow up on this quickly after that happens.

[ChihweiLHBird]

Thank you for the information! @jugmac00 @gaborbernat

[bagel897]

1. Could tox use the pyproject.toml to detect the supported python versions and use those?
2. If it helps, I'm making a library to support toml and ini configuration

[gaborbernat]

Thanks, but that will not help. tox configuration is complex and it's not possible to have the same config in ini and toml. E.g. substitutions and references don't work well in toml, so we need to design a config file/logic that's better suited for TOML.

[ketozhang]

@gaborbernat Since this issue has gotten as complicated as it is, it would be useful to have a writeup of the complexities you've mentioned.

[gaborbernat]

Mostly boils down to the ini logic cannot be used by the pyproject.toml file. That's because a TOML file is a type bound structure, while ini is just raw strings.

[ziima]

I'd like this to be implemented and I should have some time this summer to work on this. So I patched a prototype see #3309 to start with something. It has quite a number of limitations, see below, I'd like to confirm that I'm in the right direction first. I was hoping that in tox 4 this will be relatively easy, but this will be a long run. There is a bunch of things that hindered my progress and number of decisions to be made.

My initial idea: add tox.toml (with a tox section root) or pyproject.toml (with a tool.tox section root) to the list of sources.

Status of the prototype:
Tox can handle simple tox.toml with following structure:

[tox]
min_version = '4.0'
env_list = [
    'py310',
    'py39',
    'type'
]

[testenv]
deps = 'pytest'
commands = ['pytest tests']

['testenv:type']
deps = 'mypy'
commands = ['mypy src']

I completely ditched the idea of pyproject.toml, since that would also require non-negligible work or an ugly hack.

Major limitation: Tox seems still to be heavily designed around INI structure. INI files are easy, since everything in there is just a text. Despite the fact that basic APIs in TOX 4 are designed INI-neutral (or at least at first glance), I found following problems:

• env definitions: Prototype works OK with envs defined as ['testenv:quality']. It seems to me, it would me more TOML style to have them defined as [testenv.quality]. The separator to testenv : is defined quite deep, in tox.loader.section.Section and this would require quite a deep change.
• conditionals: Tox allows conditionals almost everywhere, which is cool in INI files, but doesn't quite play well with TOML files. We should agree how are we going to define those.

Known bugs and limitations:

• TomlLoader is mostly a copy of MemoryLoader. With some patching I should be able to replace it with that one.
• TomlSource is mostly a copy od IniSource. I left it as is, until a decision on testenv naming convention for TOML files is reached.
• Some options doesn't quite work in TOML config. set_env must be a single string, I wasn't able to make extras work at all. More things may be broken. I wasn't able to completely able to make config output match respective TOML and INI files with some advanced configuration I have in one of my projects.
• Tox fails to read TOML config passed as --conf if it's name is not tox.toml. It tries to load it as INI. May be true for legacy version of pyproject.toml as well.

I plan to start with some small PRs first and move gradually towards the TOML config. A feedback would be very appreciated.

[ziima]

Ad env definitions: I don't think, it's possible to use [testenv.quality] style, since it wouldn't be possible to detect which sections define testenv and there may be collisions between option names and env names. We could stick to ['testenv:quality'], but that requires quotes in TOML. Can we use [testenv-quality] similarly to how custom definitions are defined in mypy?

[gaborbernat]

It really should be tool.tox.env instead.

[ssbarnea]

Any chance we can speedup the work on this? I am more than happy to help with code reviews, testing maybe even writing some code. The INI format seems to be a permanent source of pain and I realise that tox-dev/tox-ini-fmt#42 might never be addressed, so better to spend time on this and get rid of the ini file.

IMHO it might make sense to introduce the TOML support as experimental, even not supporting all things and give us time to polish it in further. Once we get some TOML support, it should be easier to improve.

[ziima]

Experimental support is not the issue. The main problem is that INI-style config is rooted way too deep into the tox implementation. It will require some incompatible changes and I am currently not sure how should I handle those. See #3344 for example.

[gaborbernat]

The main problem is that INI-style config is rooted way too deep into the tox implementation

I do not think I agree with this. I purposefully made tox 4 not depend on ini. The only ini related is here https://github.com/tox-dev/tox/tree/main/src/tox/config/loader/ini and that is stuff you should not require touching at all.

[felix-hilden]

Wow, that was unexpectedly quick once the ball got rolling 📈 been following the issue for years! 😄 Well, after all the work for tox 4 anyway :P

Thank you so much, looking forward to using this!

[gaborbernat]

Wow, that was unexpectedly quick once the ball got rolling 📈 been following the issue for years! 😄 Well, after all the work for tox 4 anyway :P

Thank you so much, looking forward to using this!

I probably spent around 10 hours, adding the implementation with tests. To be fair, most of the heavy lifting was already done by the version 4 rewrite, which took weeks to get it done.