71–80 of 144 posts
IMO, JSON, YAML, and TOML should all interpret all keys as strings, and only enforce quotes when syntactically necessary. So, `key1` is a string and doesn't need to be quoted. `12345` as a key is interpreted as a string (because keys are strings) and doesn't need to be quoted. `"key 1"` has a space, so it needs to be quoted.
What does IMO configuration look like
The n, no, off thing is just sad. It's a 100% avoidable issue. But whoever put that into spec was just so clever that they overflew and became stupid.
Whoever thought supporting sexagesimal numbers was a good idea needs to spend some extended time away from their computer to reflect on what they’ve done
Almost all of this is solved by basically putting quotes around strings. Yaml has its uses cases where you want things json doesnt do like recursion or anchors/aliases/tags. Or at least it has had - perhaps cue/dhall/hcl solves things better. Jsonnet is another. I havent tried enough to test how much better they are.
So... what are the good alternatives to yaml? For quite some time I thought toml, but the way you can spread e.g. lists all over the document can also cause some headaches. Dhall is exactly my kind of type fest but you can hit a hard brick wall because the type system is not as strong as you think.
What about KDL ( https://kdl.dev/ ) or Pkl ( https://pkl-lang.org/ )?
Pkl seems syntactically beautiful and powerful, but having types and functions and loops makes it a lot more complicated than the dead-simple JSON data model that YAML is based on.
Earlier quoted context omitted.
> Ansible is a wonderful tool though, if you can excuse these idiosyncrasies. The only advantage Ansible has is how easy it is to start with it - you don't need to deploy agents or even understand a lot about how it works. Trouble is, it doesn't really scale. It's pretty slow when running against a bunch of machines, and large configurations get unwieldily quickly (be it because of YAML when in large documents its im…
Seems like the right answer is "bootstrap your daemon installs with Ansible and then use something that scales better that runs on those daemons." What are the best practices along these lines? What's the "something better"?
Earlier quoted context omitted.
I feel like these two tenets - (1) yaml should require quotes & (2) the value in yaml is in recursion/anchors - are fundamentally the opposite of why yaml exists & why people use it. The distinguishing draw of yaml is largely the "easiness" of not having explicit opening or - more importantly - closing delimeters. This is done using a combination of white-space delimiting for structure, & heuristic parsing for values…
> The distinguishing draw of yaml is largely the "easiness" of not having explicit opening or - more importantly - closing delimeters. Along with a coworker, I wrote the package manager for Dart, which uses YAML for its main manifest file (pubspec.yaml). The lack of delimiters is kind of nice but wasn't instrumental in the choice to use YAML. It's because JSON doesn't have comments. If there was a JSON+comments what…
This is a big plus but JSON5 has pretty widespread language library support - probably equal to that of YAML tbh (e.g. Swift has native JSON5 support, I don't know that anyone natively supports YAML). Any reason not to opt for it here?
Earlier quoted context omitted.
It depends on how they parse/decode/unmarshal the file. If they use a "generic" yaml parser, no will be translated to false. But if the parser knows the types of the data structure, or can be instructed not to replace certain strings, or has hooks, it can treat no as a string. So it might be that the linter doesn't operate like the parser.
Halloween isn't for a few more weeks, but this framework for creating bespoke YAML dialects that can only be parsed by a specific implementation and with the correct type annotations will scare the pants off of your devops colleagues around the campfire. (In case I haven't succeeded in hitting the right tone, this is intended to be good-natured jest and not snark.)
Now, JSON is more suited for machine-to-machine, but YAML works fairly well for humans. It's a pity, but a few domain specific don't really hurt, since you can't copy some bit of YAML and paste it in an entirely different config anyway.
PS campfire story? "When we were still working in the old building, deep down in the cellar, there was a colleague who had been there since the early days. Nobody saw him arrive at work or leave. It was as if he was always there. One of the things he had written was a custom parser ... FOR YAML!"
Earlier quoted context omitted.
Whoever thought supporting sexagesimal numbers was a good idea needs to spend some extended time away from their computer to reflect on what they’ve done
Presumably that was to support time values.
IMO anything other than the basic types supported by JSON (number, true, false, null) ought to be be parsed as a string. Or if you really insist, some kind of special syntax to make it clear it's not a string would probably be acceptable.