Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YAML document from hell (2023)

ruudvanasseldonk.com

Post reply on HN
Print view View original

21–30 of 144 posts

Re: YAML document from hell (2023)

#21

Post by gchamonlive »

al_borland wrote: post #2

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.

Re: YAML document from hell (2023)

#23

Post by cousin_it »

Kostarrr wrote: post #13

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.

How about textproto? And the proto definition gives the schema.

Re: YAML document from hell (2023)

#24

Post by mystifyingpoi »

vivzkestrel wrote: post #17

stupid question: why dont they announce a newer version of YAML that is not backwards compatible and allow only quoted strings in their parser?

> that is not backwards compatible

This would be a massive breaking change for Kubernetes. There are piles and piles of YAML all around the opensource that would need updating. It would be very hard to adopt.

Also, quoting strings 100% of the time just looks ugly in my opinion. Not a big deal with autogenerated YAML, or YAML that I do not maintain, but for anything handwritten it's annoying.

Re: YAML document from hell (2023)

#25

Post by kevincox »

raincole wrote: post #6

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.

It basically feels like overfitting. They saw some use case so they added it. But they didn't think about how this would generalize and now this nice use case is disproportionately supported at the cost of surprising everyone who doesn't need time-of-day fields in their file.

Re: YAML document from hell (2023)

#27

Post by bjackman »

twelvechairs wrote: post #5

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.

Yeah and this is enforced by default in yamllint.

It's very fair to cry "why the hell do I need a linter for my trivial config file format", and these footguns are a valid reason to avoid YAML.

But overall YAML's sketchiness is a pretty easy problem to solve and if you have a good reason to keep/choose YAML, and a context where adding a linter is viable, it's not really a big deal IMO.

And as hinted in the post, there's really no well-established universal alternative. TOML is a good default but it's only usable for pretty straightforward stuff. I'm personally a fan of the "just use Nix" approach but you can't put a Nix interpreter everywhere. And Cue is way overpowered for most usecases.

I guess the tldr is that the takeaway isn't "don't use YAML" but just "beware of YAML footguns, know the alternatives".

Re: YAML document from hell (2023)

#28

Post by maxbond »

tgv wrote: post #10
al_borland wrote: post #2

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.

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.)

Re: YAML document from hell (2023)

#29

Post by puzzlingcaptcha »

twelvechairs wrote: post #5

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.

from the article:

>Many of the problems with yaml are caused by unquoted things that look like strings but behave differently. This is easy to avoid: always quote all strings.

Post reply on HN