A 10 minute read covering some YAML edge-cases that you should have in mind when writing complex YAML files
You must log in or register to comment.
You shouldn’t write complex yaml files. Keep it simple and yaml is great. Do complex stuff and you’ll hate your life.
If you write your own tooling then it’s great. The vast majority of us are using other people’s tooling and have to deal with their imposed complexity. I for one hate GitHub actions with a passion.
None of the complexity of GitHub actions would be solved with any other configuration language. It needs to be a full scripting language at minimum. The problems with GHA have nothing to do with yaml.
I’m convinced everybody who told me that “GitHub actions are great!” were just part of one big prank.
Man, even knowing that YAML document was going to be laden with bullshit, I only spotted the unquoted version strings looking fishy.
I also really dislike how often YAML is abused to take keys as list items. Something like this, for example:
hosts: debian-vm: user: root database-server: user: sql“debian-vm” and “database-server” are the hostname, and as such they are values. So, this should be written as:
hosts: - name: debian-vm user: root - name: database-server user: sqlAnd I’m not just nitpicking here. If we change the example a bit:
hosts: database: user: sql…then suddenly, you don’t know, if “database” is just one of many possible hosts or if all hosts always have a shared database with this technology.
I inherited ansible that always used maps instead of lists and it drove me up the wall. Still untangling that.
Interesting read. Wish I would’ve found it years ago when I started my first DevOps gig. The company used AWS and CloudFormation (YAML, not JSON) quite a bit along with Ansible. The things I saw in that hellscape were brutal.
I read part of it; it was too painful to read more.
I kept finding myself saying “Well that’s stupid” over and over again.
Edit: To clarify, it’s yaml parsing that is “stupid”; the article was great.
Did you find the article stupid, or are you talking about yaml parsing ?
Yaml parsing. Article was great.
The problem is there aren’t really any good alternatives that have as widespread support. I’ve looked at lots and always found some annoying flaw that JSON or YAML don’t have. I mainly want good support in Python, Rust and VSCode.
- JSON5: This is my ideal alternative but it has surprisingly poor support. No good VSCode extension. There’s a Serde crate but it’s not very popular.
- Jsonnet: This has great VSCode support and support for lots of languages including Rust, but for some inexplicable reason they won’t let you use it with Serde just to load documents.
- TOML: This is just not a good format. It’s ok for very basic things but any level of nesting and it becomes even worse than YAML.
- Cue: Only supported language is Go.
There isn’t really a perfect option at the moment IMO.
If I’m using Rust I tend to go with RON at the moment. Sometimes I do use YAML but I write it as JSON (since YAML is a superset of JSON) with
# comments.Also never output YAML from your programs. You can always output JSON instead which is better.
My hierarchy goes something like this:
- A relatively trivial configuration file? TOML
- A configuration file that needs a bit of complexity and nesting? YAML
- Is it getting so complicated and longwinded that you’re actually unlikely to touch it by hand anyway? JSON
- Have we become downright enterprisey? XML
See also: noyaml.com
I personally like yaml though. Although I won’t deny it can be hellish to write without a linter, it’s just like any other language with tab autocomplete and warning for sus things if you have the right software set up.
I used the ansible and kubernetes VSCode extensions, and I really like them both. With the kubernetes one, you can just start typing the name of the resources you want to create, and then press tab, and boom, a template is created.
I would much rather see something like Nix be the norm, but I find Nix very frustrating to edit because the language servers for it are nowhere near as developed.
This is kinda my experience. If there’s an extension keeping track of schema and linting, it’s alright.
If you’re doing it by hand, well, good luck.
My personal favourite way to make configs is lua. But that’s neither here nor there.
If you’re comparing YAML with JSON, it displays that you understand neither.
JSON is designed for data exchange between systems. YAML is designed to describe data for a single system, and is always subject to individual implementations.
They are not interchangeable concepts.
all json is valid yaml and can be parsed with a yaml parser. Yaml is literally a superset of json. In what world are they not comparable?
They are both serialization formats that are supposed to be able to represent the same thing. Converting between these 2 formats is used in the article as a way to highlight yaml’s parsing quirks (since JSON only has a single way to represent the
falseboolean value, it makes it clear that thenovalue in yaml is interpreted as a booleanfalseand not as the"no"string)Anyway, I disagree with your point about YAML and JSON not being interchangeable
