<p dir="ltr">Actually, Nathaniel didn't test vendorability of the libraries, and pip needs that. Pyyaml isn't in good shape there.</p>
<div class="gmail_quote">On 8 May 2016 11:06 AM, "Alex Grönholm" <<a href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
07.05.2016, 17:48, Nick Coghlan kirjoitti:<br>
<blockquote type="cite">
<p dir="ltr"><br>
On 7 May 2016 13:00, "Nathaniel Smith" <<a href="mailto:njs@pobox.com" target="_blank"><a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a></a>>
wrote:<br>
><br>
> Here's that one-stop writeup/comparison of all the major
configuration<br>
> languages that I mentioned:<br>
><br>
> <a href="https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f" target="_blank">https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f</a></p>
<p dir="ltr">Thanks for that, and "yikes" on the comment handling
variations in ConfigParser - you can tell I've never even tried
to use end-of-line comments in INI files, and apparently neither
has anyone I've worked with :)</p>
<p dir="ltr">For YAML, my main concern isn't quirkiness of the
syntax, or code quality in PyYAML, it's the ease with which you
can expose yourself to security problems (even if *pip* loads
the config file safely, that doesn't mean every other tool
will). Since we don't need the extra power, the easiest way to
reduce the collective attack surface is to use a strictly less
powerful (but still sufficient) format.</p>
</blockquote>
Sounds like a far-fetched hypothetical problem. You're concerned
about the custom tags provided by PyYAML? Do you happen to know a
tool that defaults to loading files in unsafe mode?<br>
<blockquote type="cite">
<p dir="ltr">For ast.literal_eval, we'd still need to come up with
a way to do sections, key:value mappings and define rules for
comments.</p>
<p dir="ltr">For completeness, I'll note that XML combines even
more user unfriendly syntax than JSON with similar security
risks to YAML.</p>
<p dir="ltr">So with the trade-offs laid out like that (and
particularly the inconsistent comment and Unicode handling in
ConfigParser), I'm prompted to favour following Rust in adopting
TOML.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">P.S. I particularly like the idea of using extension
sections to eventually consolidate other static config into a
common file - that nicely addresses my concern with config file
proliferation, since it opens the door to eventually subsuming
other files like MANIFEST.in and setup.cfg as archiving and
build systems are updated</p>
<p dir="ltr">><br>
> -n<br>
><br>
> --<br>
> Nathaniel J. Smith -- <a href="https://vorpus.org" target="_blank">https://vorpus.org</a><br>
> _______________________________________________<br>
> Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a></p>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div>