Fear and Loathing in YAML
chrisshort.net
Fear and Loathing in YAML
1–10 of 107 posts
Re: Fear and Loathing in YAML
#2Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file.
I remember being pretty excited when I discovered YAML and even pushed its use in some projects trying to avoid the verbosity of XML. These days I will never trade accuracy for conciseness, in particular if its form relies on whitespace and there is not enough redundancy in the specs for consistency checks. Yes, syntax matters.
Re: Fear and Loathing in YAML
#3How much of this can be solved by using a linter like yamllint, or a a mode that validates the data via a schema or dry-run mode? I'd think it would knock out most of the low hanging fruit.
Re: Fear and Loathing in YAML
#4Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…
[deleted]
Re: Fear and Loathing in YAML
#5https://hitchdev.com/strictyaml/
Also most editors have indentation guides, which help a lot with indentation issues.
Re: Fear and Loathing in YAML
#6TOML remains severely underrated, for some reason.
It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments!
If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when I was doing this evaluation for my own project.
Re: Fear and Loathing in YAML
#7Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…
The biggest problem I find with YML is that whitespace matters, but merging tools usually are set to ignore whitespace.
So git merge will say "no merge conflicts", but actually there were whitespace changes.
Re: Fear and Loathing in YAML
#8I’d say yaml itself is the smaller part of the problem. The real fun starts when its obvious shortcomings (for use cases it’s being attempted to fulfill) are being papered over with jinja2, code in nondescript languages embedded in string values and css-like composition rules for multiple files.
Re: Fear and Loathing in YAML
#9https://hitchdev.com/strictyaml/ Also most editors have indentation guides, which help a lot with indentation issues.
Their sections on "Why StrictYAML" and "design justifications" are required reading for anyone working on a text-based serialization format.
You may not agree with all their conclusions, you may have another use case, but you ought to make sure you're addressing all those points.
Re: Fear and Loathing in YAML
#10TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…
It’s a bit too strict for configuration files and too verbose for an interchange format. It’s an improvement over JSON and arguably yaml but it won’t beat actual syntax.