Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The yaml document from hell[1] needed three changes ("*.html", "*.png", "!.git") to be parsed by yq at all. "Norway problem" is not a problem as no was converted to a quoted string. Unquoted strings in "allow_postgres_versions" part were not quoted by yq.

[1] https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...



It's a bit hard to be sure because YAML is so insane, but I would argue that yq's behaviour is not incorrect?

It is erroring on `*.html`, which is reasonable because `.html` is an invalid anchor identifier, though the error is not that useful. The parsing of the unquoted version numbers also seems to be "correct", in that things that look like numbers are supposed to be parsed as numbers.


I fully agree with the author's statement that "templating YAML is a terrible idea". Helm charts are somewhat finicky to author.

And I don't much like them as an end-user either, at least where there's a decent operator as an alternative.

(The definition of "decent" starts with "good documentation", looking at you Prometheus operator.)


Templating yaml with a text templating language like Helm's templating language is a terrible idea. Templating objects and serializing them to Yaml (with input also being Yaml) I find quite nice: https://github.com/con2/emrichen


Yep, now that is a far better approach.


Templating YAML is up there with putting lead in gas and invading Ukraine. It instantly turns me into an expletive spouting rage infested monkey.

And yes let’s not even get into the state of off the shelf charts.


1. yq appears to accept the unquoted tag !.git for me, without change? (This is at least a correct parse syntactically, I think.)

2. The unquoted aliases (*.html, *.png) are invalid: that yq errors on them is the correct output. (I.e., if you want those as literal strings, they MUST be quoted.)


i wonder if the people who worked on the YAML spec regret not string wrapping stuff? i’m sure it was by design “at the time”?


The spec says this:

"The plain (unquoted) style has no identifying indicators and provides no form of escaping. It is therefore the most readable, most limited and most context sensitive style."

Which reads to me that they expected people to treat the plain style as a convenience that had notable downsides.

Edit: Note that this is the "plain" style, where there's also single and double quoted styles.


A reasonable choice (in contrast to "no" or "null"). YAML is simply not a format for all use cases. It's good enough for many tasks, and more readable than most other formats where it fits.


> YAML is simply not a format for all use cases.

Maybe, but unquoted strings not being the right choice for all use cases (or, similarly, structure-by-indentation not being) doesn’t show that, since YAML supports unquoted and quoted strings, and supports both indent-sensitive “block style” and delimiter-based “flow style”.


To me, it doesn't fit where people with a less technical background can/must edit configuration files, or where there's a large risk of mixing up null and "null". For readability, it's fine, except for the ugly node reference syntax.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: