61–70 of 144 posts
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
I find it remarkable that YAML has become our goto for configuration when it is riddled with parsing traps and inconsistent behaviour that catches out even experienced developers
It's because other config formats aren't as expressive.
I never really understood why nobody ever just forked YAML and took out the ugly bits. It’s not a very complicated parser. In the mean time, I’m very much enjoying KDL.
The Norway problem drives me a bit nuts. In a lot of the Ansible documentation, yes/no are used instead of true/false. When seeing this in the official docs, I used it, figuring this was the preferred convention in Ansible. These days it now throws warnings or lint errors, so I’m updating it all over the places as I find it. Yet the Ansible documentation still commonly uses it.
Ansible isn't a gold standard for docs. The docs are updated and maintained, but the underlying interfaces aren't consistent and that leaks to the docs. One can only wonder why, maybe different developers with different ideas for conventions without a style guide. 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 impossible to orient/know what is where/at what level, or because of the structure of playbooks vs roles vs whatever, or because templating a whitespace-as-logic-"language" is just hell). It's also fun to debug "missing X at line A, but the error can be somewhere else". Cool, thanks for the tip.
So it's pretty great to get started with, or at a home lab. Big organisations struggling with it is a bit weird.
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.
Alas, YAML is just about everywhere, so the chances for a replacement that'll be both better behaved and as ubiquitous are unfortunately slim.
Earlier quoted context omitted.
Ansible isn't a gold standard for docs. The docs are updated and maintained, but the underlying interfaces aren't consistent and that leaks to the docs. One can only wonder why, maybe different developers with different ideas for conventions without a style guide. Ansible is a wonderful tool though, if you can excuse these idiosyncrasies.
> 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…
What are the best practices along these lines? What's the "something better"?
I wonder if you could make a new standard something based on yaml where every value was prefixed by a type so there is no ambiguity.
We found yaml to be a great exchange format for electronic exam data. It allows us to put student submitted answers and source code into a yaml file and there is no weird escaping. It's very readable with a text editor. And then we just add notes and a score as a list below and then there's the next submission. For readability of large blocks of texts that may or may not contain various special characters and newline…
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.
We'd have to change the spec and then all the core libs. Big task. Use more quotes, use yamllint. Like bash, more quotes and shellcheck.