TOML development has stalled - implications for pyproject.toml and a way forward?

One other point I think is worth making. The pyproject.toml format was designed for packaging configuration. While we included a reserved [tool] section for tool-specific configuration, there was no intention at the time to define a format that was capable of handling every possible type of configuration data.

While it’s certainly true that putting configuration in pyproject.toml has become far more popular than we[1] expected, it’s hardly the fault of the format if it’s being pushed to its limits by certain projects. For example, there’s no reason pydoc-markdown couldn’t store its config in a YAML file if that format makes it easier to express the necessary configuration.


  1. Or at least I ↩︎

1 Like

I think developers have been yearning for a standard place to put configuration hence the uptake of [tool]. pydoc-markdown can in fact use its own YAML file, but I have found it convenient to have all configuration in one place so I can easily keep my projects updated and I don’t like having multiple configuration files in the root of projects.

What could be a better solution than putting all tools configuration in pyproject.toml is if a standard folder could be decided upon in which all tools look for their configuration (they could still look in other places as well as the standard location if desired). One example I have come across is an attempt to standardise the .config folder.

2 Likes

if anyone needs me i’ll just be over here innocently stroking my cat :cat2:

15 Likes

I think developers have been yearning for a standard place to put configuration

A table of contents for a doc site seems like it’s really stretching the idea of “configuration”. I might want to consolidate my dev tool configuration in pyproject.toml, but (a) a documentation site is a first-class product and deserves its own spec file(s) and (b) I really don’t want to understand TOML enough to do something like that. I think YAML is a much better choice, and it is in fact what mkdocs is already using for this purpose.

Apologies if I’m veering too far off topic…

2 Likes

Wow, is that what that data was? In which case yes, IMO it’s a really bad decision on the part of pydoc-markdown to put it into pyproject.toml.

But yes, I think this is pretty off-topic by now (not your fault, it had drifted a long time ago).

Regarding the original post:

  1. TOML development may or may not have stalled, that’s not a matter for Python. And it seems like it hasn’t, it’s just bottlenecked on people’s time, which is hardly unusual in open source.
  2. There are no real issues for Python, standard uses of pyproject.toml are served just fine by the current version of TOML. And non-standard uses don’t have to go in pyproject.toml if the format is a bad fit.

Thanks for all the discussion here. I just want to clarify that when I referred to TOML development stalling in the title, I should have been clearer as it could have been taken that people had stopped working on TOML altogether which wasn’t what I meant. I should have put a title that was more specific about the release process for TOML looking like it had stalled and needing more maintainers and I’m sorry for not being clearer.

I’ve found your responses really helpful in guiding where configuration should go. I had assumed by the enthusiastic uptake by tools developers using [tools] that the goal had been to get everyone to put configuration there. It is clear that I was mistaken and I think I’ll move towards having a configuration folder and limit what’s in pyproject.toml. Thank you all for your help!

4 Likes