[Distutils] comparison of configuration languages

[Brett Cannon]

On Sat, 7 May 2016 at 07:49 Nick Coghlan <ncoghlan at gmail.com> wrote:

>
> On 7 May 2016 13:00, "Nathaniel Smith" <njs at pobox.com> wrote:
> >
> > Here's that one-stop writeup/comparison of all the major configuration
> > languages that I mentioned:
> >
> > https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f
>
> 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 :)
>
Yeah, that's pretty bad. :/ I checked when ConfigParser was added to Python
and it's late 1997: https://hg.python.org/cpython/rev/5b24cbb1f99b, so
rather old and predates our stricter code quality rules for additions to
the stdlib.



> 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.
>
> 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.
>
> For completeness, I'll note that XML combines even more user unfriendly
> syntax than JSON with similar security risks to YAML.
>
> 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.
>
+1 for TOML from me as well. I know Paul brought up the lack of
familiarity, but the format is simple and the Rust community is already
fully dependent on it so at worst Rust + us could always just ignore future
format versions if necessary.

If TOML is the chosen format we could ask how long until a 1.0 release to
know if we waited a month or so to implement we could make sure we're
compliant with that version.

I also checked pytoml at https://github.com/avakar/pytoml and it looks like
it's pretty stable; no changes in the past 5 months except to support
Python 3.5 and only 3 issues. And the format is simple enough that if
someone had to fork the code  like Nathaniel suggested or we did it from
scratch it wouldn't be a huge burden.

-Brett


> Cheers,
> Nick.
>
> 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
>
> >
> > -n
> >
> > --
> > Nathaniel J. Smith -- https://vorpus.org
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160507/24cee00f/attachment.html>