131–140 of 144 posts
Earlier quoted context omitted.
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.
Specs change from time to time. It requires effort. Nothing new here. It's necessary sometimes. Dealing with annoyances and footguns also takes effort.
Earlier quoted context omitted.
INI-like formats are perfectly fine for config files with at most one layer of nesting/sections. TOML is a perfectly fine INI-like parser. Its definitions and support for strings, numbers, comments, sections and simple arrays are great. But its main claim to fame is extending INI to support arbitrary levels nesting of arrays and dictionaries like JSON, and IMO it does a horrible job at it. With JSON, YAML, XML and ma…
> And the more nested the format becomes, with arrays of dicts, or dicts of arrays, the harder it is to follow. While I have some minor annoyances with TOML, I counterintuitively consider it a strength of the format that nesting quickly becomes untenable, because it produces pressure on the designers of config file schemas to keep nesting to a minimum. Maybe some projects have a legitimate need for something more com…
Earlier quoted context omitted.
Has this really been a problem in the last ten years? Version 1.2 of the spec (if I recall) fixed it in 2009.
Only if you use Kubernetes, because it’s YAML 1.1 all the way.
Earlier quoted context omitted.
> And the more nested the format becomes, with arrays of dicts, or dicts of arrays, the harder it is to follow. While I have some minor annoyances with TOML, I counterintuitively consider it a strength of the format that nesting quickly becomes untenable, because it produces pressure on the designers of config file schemas to keep nesting to a minimum. Maybe some projects have a legitimate need for something more com…
As far as I can see, nobody originally constrained the problem to config files. So I guess the problem with TOML is that it's only good for config files, while JSON and TOML are general purpose.
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…
What is so verbose about a cdata directive? Everybody complains about XML being verbose, never once heard complains about HTML being too verbose.
> There exist various extensions of json that extend it just enough to make it a usable config format without introducing too much complexity. Json with comments is probably the most widespread, as it is used as the config format for Visual Studio Code. The main downside of these is that they haven’t really caught on (yet!), so they aren’t as widely supported as json or yaml. What blew my mind was learning that the e…
Earlier quoted context omitted.
Only if you use Kubernetes, because it’s YAML 1.1 all the way.
Forgot to add a source: https://github.com/kubernetes/kubernetes/issues/34146#issuec...
Sometimes the tech world moves at warp speed, sometimes it just treads water.
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.
It's very counter-intuitive to me that 22:22 would need to be a quoted string, since functionally it's a K-V-pair. YAML itself even uses : in the Dict syntax!