
On 10 May 2016 at 08:38, Alex Grönholm <alex.gronholm@nextday.fi> wrote:
A few facts:
YAML is good enough for Salt, Ansible and numerous other common tools The YAML standard has been stable for many years, unlike TOML which still hasn't even reached 1.0 YAML has widespread tooling support, unlike TOML
We all agree that JSON is not the solution. No comments, trailing commas etc. TOML isn't much better than ConfigParser in terms of representing nested structures.
Just as another data point, Cookiecutter started off using pyYAML, moved to ruamel.yaml, and ended up with their own (separated out into an independent project, but written specifically for Cookicutter) implementation of "some of" YAML, called poyo. I believe the reason they did this was repeated issues with the existing YAML libraries. And while the YAML-subset provided by poyo *looks* reasonable, I don't see any documentation of precisely *what* subset of YAML is implemented (apart from some examples). The poyo library is also very new, and I doubt it's seen much usage/testing outside of cookiecutter so far. I would love to use YAML. I really would. But for pip, we need a robust, easy to vendor Python implementation (with no C dependency) that is safe (see http://community.embarcadero.com/blogs/entry/yaml-and-remote-code-execution-...). Writing our own is simply a way to end up with additional maintenance work, that we really don't have the resources for.
So far the ONLY objective problems with YAML seems to be the problematic implementation named PyYAML. If this is really the case, I'd gladly help build a better one just to prevent TOML from being chosen for this task.
If you can get a robust, stable YAML library written fast enough to be an option for the PEP, then that would certainly be a possibility. But given that poyo has been under development for 5 months, are you going to be able to do better than that in a few weeks? (And see my comments above on poyo).
That we're even considering building something as important as this on an unstable standard is pretty horrifying to me in itself.
Well, IMO, the state of things in terms of config file formats (and not just in Python) is itself pretty dreadful - every time I write an application, I am astounded that there are no good options for something as basic as a configuration file format. Paul