Live data from Hacker News

Why are we templating YAML?

leebriggs.co.uk

171–180 of 351 posts

Re: Why are we templating YAML?

#171

My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren't sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) p…

Build files (e.g. makefiles are their various descendants like SCons, rake, etc) seem to be in the same general boat except very early on mixing "real languages" (or at least shell scripting) was obviously allowed so they've always leaned far more towards the "yes, it is a general purpose language" end of the spectrum.

Re: Why are we templating YAML?

#172
post #145

Earlier quoted context omitted.

I find YAML to be almost unusable. IMO it's just not intuitive. If I get to choose a format for my config files I would only use TOML, it's just better (again IMO).

Agreed. From readability perspective, I started out with INI, which I ditched partially due to having no standard on the format and skipped JSON when it can't add comments, skipped YAML for not looking too intuitive, considered JSON5 but skipped for being not popular enough and landed on TOML.

And I skipped toml for an object-array syntax that makes baby Jesus cry.

None of these problems are hard, why are all the solutions so awful?

Re: Why are we templating YAML?

#173
post #128

Earlier quoted context omitted.

I have been using ksonnet but that is now officially dead. Working with jsonnet seemed unnecessarily painful when coming from coding typescript. This information is quite timely and welcome, I'll look further at the ts example.

We have ksonnet expats on the team (we're all in cloud city -- Seattle), and I've been keeping an eye on that project myself, since I think it got a lot of things right and frankly many of the ideas for Pulumi were inspired by early chats with the Heptio team. But, as you say, why create a new language when an existing one will do -- that was our original stance and it's working great in practice. Joe Beda will be do…

OP here. I actually wrote a post about Pulumi in this very space a while back

https://leebriggs.co.uk/blog/2018/09/20/using-pulumi-for-k8s...

I do think this is more like what we should be doing, but as dismayed to see Pulumi’s free tier get sunsetted

Re: Why are we templating YAML?

#174

I know I'm in a minority, but I really dislike YAML... I recently did a lot of Ansible and boy, at the beginning, I was just struggling a lot. Syntactic whitespace kills me. I don't like it in Python either, but for some reason, when I write Python, it's a lot easier. Maybe YAML is just a bit more complex (and Python has better IDE support..?)

I like looking at YAML when it doesn't use any of the insane YAML features. Even so I'm not convinced it should be used (at least not as widely as it is) for one big reason: it can be truncated almost anywhere and still be valid. This causes way more issues than you might think. JSON has no such issue - the only case I can think of where you can truncate JSON into valid JSON is if your JSON is just a number.

Re: Why are we templating YAML?

#175
post #153

Earlier quoted context omitted.

I know you only said Python is better, not great, but you might want to check out OpsMop: https://medium.com/@michaeldehaan/opsmop-building-the-next-g... . By the creator of Ansible, in pure Python, including the config.

Is there a reason http://opsmop.io/ and http://vespene.io/ are both down and their Github's both say "DISCONTINUED"? https://github.com/opsmop/opsmop https://github.com/vespene-io/vespene

I... No. The OpsMop Twitter has a tweet from January 31, so it seems like if the project had died it would have to be really recent. That would be sad.

Re: Why are we templating YAML?

#176
post #153

Earlier quoted context omitted.

I know you only said Python is better, not great, but you might want to check out OpsMop: https://medium.com/@michaeldehaan/opsmop-building-the-next-g... . By the creator of Ansible, in pure Python, including the config.

Is there a reason http://opsmop.io/ and http://vespene.io/ are both down and their Github's both say "DISCONTINUED"? https://github.com/opsmop/opsmop https://github.com/vespene-io/vespene

Michael DeHaan threw his toys out of the pram because he wasn’t getting the user numbers he wanted and discontinued them

Re: Why are we templating YAML?

#177

Earlier quoted context omitted.

> I don't like any language or file format where whitespace matters. .... To me white space shouldn't add cognitive load. 1. there is no language where whitespace does not matter 2. the very purpose of indentation is to ease cognitive load. Now, you may not want it to be inflexible or mandatory but your argument needs elucidating.

Ok: I don't like any language of file format where the regex s/\s+/\s/g would change the meaning of the program except in parts of the program within string delimiters, except for the parts of string delimiters which contain literal code e.g. ins ES6 `Hello ${world}`.

OK, but I'd restrict the set even more to exclude voluntary indentation. I mean, you'd want that caught by style checkers anyway, even if the language didn't require it.

So we're left with the cases where you'd like compact code / one-liners but are forced to use multiple lines for language syntax reasons.

I'd say that that's a pretty small set of cases and long way from the phrase "I don't like whitespace sensitive languages" which you (and many others!) use.

I conceded it can be annoying in Python and I do wish there was an escape route sometimes.

Re: Why are we templating YAML?

#178
post #172
post #145

Earlier quoted context omitted.

Agreed. From readability perspective, I started out with INI, which I ditched partially due to having no standard on the format and skipped JSON when it can't add comments, skipped YAML for not looking too intuitive, considered JSON5 but skipped for being not popular enough and landed on TOML.

And I skipped toml for an object-array syntax that makes baby Jesus cry. None of these problems are hard, why are all the solutions so awful?

What are you using now?

Re: Why are we templating YAML?

#179

Earlier quoted context omitted.

> It's a solved problem For who, exactly?

For anyone using EC2 Parameter Store, a free service in AWS: > Parameters: > AMI: > Type: AWS::SSM::Parameter::Value > Default: /aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id Gives you the latest, fully patched Linux OS in any of 19 regions that you launch it in. Free K/V store that works really well for apps and custom parameters.

Well, that’s great for anyone using the EC2 parameter store, but isn’t really helpful for all those situations where you’re not.

“This is not a problem for my specific set of use cases around AWS” is not a “solved problem”

Re: Why are we templating YAML?

#180

Earlier quoted context omitted.

I find YAML to be almost unusable. IMO it's just not intuitive. If I get to choose a format for my config files I would only use TOML, it's just better (again IMO).

All these comments amuse me, because I feel the opposite. YAML has always made immediate intuitive sense to me. Meanwhile TOML feels like a terrible hack. Also, I'm guessing I'm in a tiny minority who loves YAML but hates Python's semantic indentation...

I'm the same way. I think it's a difference in my expectations of a programming language versus a hierarchical data storage format. I'm fine with (and even prefer) enforced whitespace in data formats. That makes it easier to view and edit.

In programming languages, it makes me twitch. I don't have any problem with "accepted" formatting styles (i.e. linux kernel c style), but for the language itself to enforce that for some reason feels like it's adding perpetual cognitive overhead (like whenever I use python). I don't know why; it shouldn't be any different than using a particular formatting style voluntarily in a more flexible language, but somehow, it feels different.

Post reply on HN