<div dir="auto"><div>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.</div><div dir="auto"><br></div><div dir="auto">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.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Mon, Oct 8, 2018, 8:03 AM Anders Hovmöller <<a href="mailto:boxed@killingar.net">boxed@killingar.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
>> He's referring to PEPs 518 and 517 [1], which indeed standardize on<br>
>> TOML as a file format for Python package build metadata.<br>
>><br>
>> I think moving anything into the stdlib would be premature though –<br>
>> TOML libraries are under active development, and the general trend in<br>
>> the packaging space has been to move things *out* of the stdlib (e.g.<br>
>> there's repeated rumblings about moving distutils out), because the<br>
>> stdlib release cycle doesn't work well for packaging infrastructure.<br>
> <br>
> If I had the energy to argue it I would also argue against using TOML<br>
> in those PEPs.  I personally don't especially care for TOML and what's<br>
> "obvious" to Tom is not at all obvious to me.  I'd rather just stick<br>
> with YAML or perhaps something even simpler than either one.<br>
<br>
This thread isn't about regretting past decisions but what makes sense given current realities though.<br>
<br>
/ Anders<br>
</blockquote></div></div></div>