I agree here. I briefly urged against using the less used TOML format, but
I have no real skin in the game around packaging. I like YAML, but that's
also not in the standard library, even if more widely used.
But given that packaging is committed to TOML, I think that's a strong case
for including a library in stdlib. The PEP 517/518 authors had their
reasons that were accepted. Now there is broad ecosystem that is built on
that choice. Let's support it.
On Mon, Oct 8, 2018, 8:03 AM Anders Hovmöller
He's referring to PEPs 518 and 517 , which indeed standardize on TOML as a file format for Python package build metadata.
I think moving anything into the stdlib would be premature though – TOML libraries are under active development, and the general trend in the packaging space has been to move things *out* of the stdlib (e.g. there's repeated rumblings about moving distutils out), because the stdlib release cycle doesn't work well for packaging infrastructure.
If I had the energy to argue it I would also argue against using TOML in those PEPs. I personally don't especially care for TOML and what's "obvious" to Tom is not at all obvious to me. I'd rather just stick with YAML or perhaps something even simpler than either one.
This thread isn't about regretting past decisions but what makes sense given current realities though.