3 ms·

INI has no spec, and there are many variations all slightly incompatible with each other, kinda like Markdown. YAML is really the only sane configuration langua

INI has no spec, and there are many variations all slightly incompatible with each other, kinda like Markdown. YAML is really the only sane configuration language that lets you denote nested structures while keeping them look nested. Basically, all of the problem identified in the article can be dealt with 1 rule - always quote your strings. I agree with the author we should have reduced, safe and minimalist subset of yaml, which is basically YAML 1.2, released in 2009. P.S. Please just stop using PyYAML.

jwilk 4y ago
> Please just stop using PyYAML. Why?
- wyuenho 4y ago
  From the article: Although yaml 1.2 is more than 10 years old by now, you would be mistaken to think that it is widely supported: the latest version libyaml at the time of writing (which is used among others by PyYAML) implements yaml 1.1 and parses 22:22 as 1342.
talideon 4y ago
I second that. And if people need to deal with YAML in Python, they should be using ruamel.yaml, which is a far superior library on just about every level: https://pypi.org/project/ruamel.yaml/ https://pypi.org/project/ruamel.yaml/
- wyuenho 4y ago
  Or if you want to go really minimalist there's also https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml
- lylecheatham 4y ago
  Except that the author of ruamel.yaml: refuses to use git [0] refuses to take community submissions (except through Stack Overflow? Seems like a misuse of SO) [1] and refuses to implement .dumps() [2]. He is difficult to work with, and any time I need to debug code that intimately deals with ruamel.yaml types, I wince. [0] https://github.com/pycontribs/ruyaml/issues/1 https://github.com/pycontribs/ruyaml/issues/1 [1] https://yaml.readthedocs.io/en/latest/contributing.html https://yaml.readthedocs.io/en/latest/contributing.html [2] https://stackoverflow.com/a/63179923/15170511 https://stackoverflow.com/a/63179923/15170511
  - talideon 4y ago
    Why would I care that the maintainer prefers Mercurial? The document you linked to doesn't say anything about them not taking community submissions: I think you need to scroll down further in the page. And it certainly doesn't say that you have to use SO to submit changes.
mike_hearn 4y ago
There's HOCON which is pretty good if you can run on a JVM. It's a superset of JSON designed for readability and human-friendliness when writing config files. It doesn't change the type system and doesn't have yamls weird edge cases, but is still a lot easier to write than JSON. There's also a relatively tight spec. https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md We use an extended version of it for our app and the resulting config is pretty clean. You can see an example here: https://hydraulic.software/blog/8-packaging-electron-apps.html https://hydraulic.software/blog/8-packaging-electron-apps.ht... The only downside is that the reference implementation is hardly maintained anymore.

jwilk 4y ago

> Please just stop using PyYAML. Why?

wyuenho 4y ago
From the article: Although yaml 1.2 is more than 10 years old by now, you would be mistaken to think that it is widely supported: the latest version libyaml at the time of writing (which is used among others by PyYAML) implements yaml 1.1 and parses 22:22 as 1342.

talideon 4y ago

I second that. And if people need to deal with YAML in Python, they should be using ruamel.yaml, which is a far superior library on just about every level: https://pypi.org/project/ruamel.yaml/ https://pypi.org/project/ruamel.yaml/

wyuenho 4y ago
Or if you want to go really minimalist there's also https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml
lylecheatham 4y ago
Except that the author of ruamel.yaml: refuses to use git [0] refuses to take community submissions (except through Stack Overflow? Seems like a misuse of SO) [1] and refuses to implement .dumps() [2]. He is difficult to work with, and any time I need to debug code that intimately deals with ruamel.yaml types, I wince. [0] https://github.com/pycontribs/ruyaml/issues/1 https://github.com/pycontribs/ruyaml/issues/1 [1] https://yaml.readthedocs.io/en/latest/contributing.html https://yaml.readthedocs.io/en/latest/contributing.html [2] https://stackoverflow.com/a/63179923/15170511 https://stackoverflow.com/a/63179923/15170511
- talideon 4y ago
  Why would I care that the maintainer prefers Mercurial? The document you linked to doesn't say anything about them not taking community submissions: I think you need to scroll down further in the page. And it certainly doesn't say that you have to use SO to submit changes.

mike_hearn 4y ago

There's HOCON which is pretty good if you can run on a JVM. It's a superset of JSON designed for readability and human-friendliness when writing config files. It doesn't change the type system and doesn't have yamls weird edge cases, but is still a lot easier to write than JSON. There's also a relatively tight spec. https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md We use an extended version of it for our app and the resulting config is pretty clean. You can see an example here: https://hydraulic.software/blog/8-packaging-electron-apps.html https://hydraulic.software/blog/8-packaging-electron-apps.ht... The only downside is that the reference implementation is hardly maintained anymore.