4 ms·

I moved some config files from json to yaml. Maintaining the documentation became a lot easier, because before I had a document describing every config option,

by Sujeto 3y ago

I moved some config files from json to yaml. Maintaining the documentation became a lot easier, because before I had a document describing every config option, which I had to maintain separately, instead now I have comments in the config file itself.

bonzini 3y ago
Note that now you have "the Norway problem" instead. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/ There's a whole spectrum of config formats including JSON, JSON5, strict YAML, YAML. It's quite messy.
- GuB-42 3y ago
  I found yaml to be surprisingly complex and tricky to write for how simple it looks. It is made to be beautiful and easy for a human to read, but the trade-off are a lot of implicit rules you need to be aware of.
  - pydry 3y ago
    The point of strictyaml is to fix that. The trade off is that you need to define a schema up front.
- riffraff 3y ago
  The norway problem is not a problem if you use yaml 1.2. Which is 14 years old. EDIT: this sounded adversarial which was not my intention. Plenty of libraries do not support 1.2 which sucks, I just meant that it's something solved in theory a long time ago.
  - debugnik 3y ago
    Could you explain further? The link contradicts this: > The most tragic aspect of this bug, however, is that it is intended behavior according to the YAML 1.2 specification. The real fix requires explicitly disregarding the spec - which is why most YAML parsers have it.
    - detaro 3y ago
      The link is wrong. YAML 1.2 fixed this.
    - riffraff 3y ago
      the article is wrong, from what I can tell. From https://yaml.org/spec/1.2.2/ext/changes/ https://yaml.org/spec/1.2.2/ext/changes/ > Changes in version 1.2 (revision 1.2.0) (2009-07-21) > [...] > Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts are parsed as strings. Underlines _ cannot be used within numerical values.

by Sujeto 3y ago

bonzini 3y ago

Note that now you have "the Norway problem" instead. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/ There's a whole spectrum of config formats including JSON, JSON5, strict YAML, YAML. It's quite messy.

GuB-42 3y ago
I found yaml to be surprisingly complex and tricky to write for how simple it looks. It is made to be beautiful and easy for a human to read, but the trade-off are a lot of implicit rules you need to be aware of.
- pydry 3y ago
  The point of strictyaml is to fix that. The trade off is that you need to define a schema up front.
riffraff 3y ago
The norway problem is not a problem if you use yaml 1.2. Which is 14 years old. EDIT: this sounded adversarial which was not my intention. Plenty of libraries do not support 1.2 which sucks, I just meant that it's something solved in theory a long time ago.
- debugnik 3y ago
  Could you explain further? The link contradicts this: > The most tragic aspect of this bug, however, is that it is intended behavior according to the YAML 1.2 specification. The real fix requires explicitly disregarding the spec - which is why most YAML parsers have it.
  - detaro 3y ago
    The link is wrong. YAML 1.2 fixed this.
  - riffraff 3y ago
    the article is wrong, from what I can tell. From https://yaml.org/spec/1.2.2/ext/changes/ https://yaml.org/spec/1.2.2/ext/changes/ > Changes in version 1.2 (revision 1.2.0) (2009-07-21) > [...] > Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts are parsed as strings. Underlines _ cannot be used within numerical values.