Why are we templating YAML?

Post by setr » Fri, Feb 08, 2019, 2:08 AM UTC

amanzi wrote: post #42

setr wrote: post #38

Earlier quoted context omitted.

I think its because python has very strict and very simple indentation rules (a nested block must be indented, and the file requires consistent indentation. Is there anything else?) YAML gives you options, or varies necessity somewhat arbitrarily on the structures, which is (marginally) good for reading, but a lot of headache in writing

Also because the longer the YAML file, the bigger your indentation gets. It gets exponentially worse as you go.

Post by quickthrower2 » Fri, Feb 08, 2019, 2:11 AM UTC

crdoconnor wrote: post #26

quickthrower2 wrote: post #4

Earlier quoted context omitted.

Baffles me. I don't like any language or file format where whitespace matters. Even Haskell bothers me in this regard. To me white space shouldn't add cognitive load. I want to look at the symbols not the formatting of the antisymbols to understand what is going on. Write JSON and use your editor tools to format it with nice indentation, and you are sweet! That said Yaml makes an excellent format for reading, but not…

I never quite understood this attitude. Not treating whitespace as meaningful means it's necessary to have a longer, syntactically noisier file. That's fine if you're primarily concerned with computers exchanging data (JSON) but where readability and writability matters, extra syntactic weight is a headache. I can't imagine writing JSON by hand but I write plenty of YAML by hand every day without issues.

Post by alexk » Fri, Feb 08, 2019, 2:14 AM UTC

jrockway wrote: post #79

I saw this title and immediately knew the article would be about Helm. I don't think anyone wants to use Helm. People use it for a set-and-forget thing that they don't care about (who cares that it's called impressive-leopard-kubernetes-dashboard, after all.) kustomize is much more sane for your own stuff: https://github.com/kubernetes-sigs/kustomize It is actually a little bit too magical for my taste, but I continu…

Post by rbankston » Fri, Feb 08, 2019, 2:18 AM UTC

guitarbill wrote: post #75

deathanatos wrote: post #45

Earlier quoted context omitted.

Easier to read and write than JSON. JSON requires constant quoting, can't support multiline strings, has no comments, has no/little typing (e.g., no datetime type). It's not good if a human needs to encode data. For configs, I think TOML beats YAML hands down; I think YAML's spot is at encoding data structures that humans need to read/write. I do agree that YAML, the spec, is fairly complicated. But YAML, as used in…

It's worth giving Ansible some credit here. Alternatives like Chef, can and do contain arbitrary Ruby logic which can make Chef "cookbooks" horrible to figure out and debug. So while Ansible may not be great, other solutions also have drawbacks, and it isn't quite as easy as do .

Post by astine » Fri, Feb 08, 2019, 2:25 AM UTC

pytester wrote: post #87

chriswarbo wrote: post #64

Earlier quoted context omitted.

> If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible world. I actually really like the idea behind XSLT: machine-friendly, human-tolerable, structured data + declarative rules for turning that data into a display, or a report, or whatever else. The execution was horrible though: incredibly verbose, lots of overcomp…

XSLT was one in a litany of domain specific languages (ant, apache rewrite rules, latex macros, etc.) that evolved towards turing completeness because that's what the problem space demanded. In most if not all of these cases an existing and well designed turing complete programming language would likely have better served them.