[FR] Tool-specific toml config

[webknjaz]

Is your feature request related to a problem? Please describe.

I maintain enough projects to have a need to synchronize the configs occasionally. Synchronizing configs where sections tend to get shuffled is rather tricky on scale, which is one of the reasons for keeping configs in tool-specific files (the other reason, for me, is that it also makes it obvious where to look for a config right away). Some projects also make use of git skeletons that employ git merge to synchronize configs that are primarily maintained in an upstream "skeleton" repository to downstreams that may occasionally diverge over time — in such case, having configs separate also helps with reducing merge conflicts a lot.

.coveragerc already solves this problem, but since the ecosystem seems to be moving away from plain INI files (because of some shortcomings) towards using TOML, it seems natural for coverage.py to also have a TOML version of such a config.

Why not pyproject.toml? It's suitable for people who don't have to maintain similar configs for different tools across many projects, which is not my case, hence the feature request...

Describe the solution you'd like

I think there should be a .coveragerc.toml where people could put their configs that would take precedence over all other files (provided that either of tomli or tomllib is importable). I expect that the structure (section names etc.) would be exactly the same as for pyproject.toml to allow for easy migration between the two (plus, it's easier to maintain as the parsing code could essentially be the same).

Describe alternatives you've considered

Keeping the config in .coveragerc.

Additional context

One example of using the Git skeleton approach is https://blog.jaraco.com/skeleton/. Among other tools following this approach are Towncrier (supports towncrier.toml and pyproject.toml with the section name [tool.towncrier]) and pip-tools (supports .pip-tools.toml and pyproject.toml with the section name [tool.pip-tools]; release pending).

[nedbat]

If you are going to have a separate file for each tool, then explain why .coveragerc isn't good? What's wrong with the .ini format for coverage's settings?

You can put configuration in a .coveragerc.toml file, but you need to specify it on the command line or in the COVERAGE_RCFILE environment variable.

[webknjaz]

.coveragerc is good and I'll keep using it. I just wasn't sure if it'll get deprecated at some point. Really, my motivation here is just bring attention to such a possibility.

I know that I can rename the file and pass it explicitly but that's not something I'd want to do since different tools are called in different contexts outside of what I set up, sometimes. For example, if I set up flake8 to run through tox+pre-commit, I'd still want the end-user' editors that use some native integrations to pick up the same config automatically, zero friction, which is only possible if the file is picked up by default.

Though, again, I'm not going to be too upset if I'll need to stick with an ini file..

[nedbat]

We'll keep an eye on it and see if other tools start adopting a tool-specific.toml file pattern.

[trajano]

• ruff
• pyright
• poetry
• black
• isort

Are a few tools that adopted tool specific toml pattern

[webknjaz]

Also, Hatch and PyLint.

[nedbat]

It seems there is growing support for this style of flexibility. If someone is interested in making a pull request, we can work on getting it merged.

[webknjaz]

@nedbat does this deserve a good first issue label? Should be easy enough, right?

[OlenaYefymenko]

@nedbat does this deserve a good first issue label? Should be easy enough, right?

@webknjaz, UPD: I'm going to work on it and finish between next Monday and Wednesday.