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

Why are we templating YAML?

leebriggs.co.uk

Post reply on HN
Print view View original

191–200 of 351 posts

Re: Why are we templating YAML?

#191

Post by crooked-v »

joeduffy wrote: post #57

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…

To go with your general line of thought, see how many JS-based projects are increasingly moving towards a JS file with a default export as a config file.

Re: Why are we templating YAML?

#193

Post by jeremysalwen »

When I joined Google, I realized that it was kinda surprising I hadn't seen something like GCL in the outside world (not to say it doesn't exist, just it's ubiquitous enough for me to hear about it). This seems to be an example of that hole being filled.

Re: Why are we templating YAML?

#194

Post by pjmlp »

Waterluvian wrote: post #111
joeduffy wrote: post #57

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…

In ROS we have these XML launch files that are just awful. They have enough features to be a really bad programming language for configuring and launching (often conditionally) numerous robot software nodes. In ROS2 the launchfile can now just be a Python script. Very much learned all this the hard way and the solution was to just support Python. I think it's brilliant.

AOLServer and our own Tcl based application server also used this idea.

Configuration files for each component were a DSL made of Tcl functions. Each module just sourced the respective file on load.

Re: Why are we templating YAML?

#195

Post by pjmlp »

tomrod wrote: post #78
atombender wrote: post #71

Earlier quoted context omitted.

YAML is a bit bonkers in that it's a superset of JSON (all valid JSON is valid YAML), so if you don't like the whitespace sensitivity, you can write your YAML like this: { a: 42, # But you can have comments! b: "hello world", c: "and multi-line strings!", # and trailing commas! }

Oh hey, a Python dictionary that throws an error. Just kidding -- faced a JSON parsing issue today and this made me smile. It's a step up from XML though.

For me lack of validation and comments are many steps down, not up.

Re: Why are we templating YAML?

#196

Post by pjmlp »

NicoJuicy wrote: post #181
miohtama wrote: post #50

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. Even though YAML is not optimal, it is a human friendly compromise between too verbose XML and machine only JSON. It lacks native templating, leading to funny constructs e.g. with Ansible files. However human kind has made progress and will make progress fur…

I actually like XML templating, it's the only one that supports it in the file. I export custom queries for data to xml, Json, CSV and HTML. Where HTML is XML + XSLT. It works great. And clients can even theme it

I also like it, for a couple of years my web site was XML + XSLT.

Re: Why are we templating YAML?

#197

Post by joeduffy »

jaxxstorm wrote: post #173
joeduffy wrote: post #137

Earlier quoted context omitted.

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

Our free tier is still there and here to stay. What did we do to make you think it's been sunsetted? :-(

Re: Why are we templating YAML?

#198

Post by ff_ »

joeduffy wrote: post #57

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…

This is a great analysis, but it's missing a fundamental point: why do we have a problem with these approximations of a programming language or just using a programming language to template stuff?

Because your build then becomes an actual program (i.e. Turing complete) and you have to refactor and maintain it! This is the common problem of using a "programming language as configuration" (e.g. gulp?)

Dhall solves exactly this problem: https://dhall-lang.org

It has the same premises of Pulumi, but without the Turing completeness (I don't know if/how Pulumi avoids that, but if it does it should be part of the pitch), so you cannot shoot yourself in the foot by building an abstraction castle in your build system/infrastructure config.

We use it at work to generate all the Infra-as-Code configurations from a single Dhall config: Terraform, Kubernetes, SQL, etc.

And there is already an integration with Kubernetes: https://github.com/dhall-lang/dhall-kubernetes

Re: Why are we templating YAML?

#199

Post by dagss »

miohtama wrote: post #50

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. Even though YAML is not optimal, it is a human friendly compromise between too verbose XML and machine only JSON. It lacks native templating, leading to funny constructs e.g. with Ansible files. However human kind has made progress and will make progress fur…

What you say you want is XSLT though, just wity a better syntax and for YAML. XSLT was just fine, had a lot of very good ideas, just horrible syntax.

Horrible syntax is kind of a forgivable offense, lots of things have horrible syntax and work fine.

Generating YAML with go templates though.. it is just horrible on so many levels.

I definitely feel the 90s can take the higher ground over 2010s on this one.

Re: Why are we templating YAML?

#200

Post by saagarjha »

ravenstine wrote: post #135
BossingAround wrote: post #27

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

> Syntactic whitespace kills me. Okay, I'm gonna be the asshole in the room, but how hard is it to just use consistent indentation? I can't count how many times I've heard people complain about significant whitespace in languages. Not only is it not difficult to begin with, but every code editor and IDE will show you where there's a syntax error in your YAML. People are free to dislike YAML, even for its significant…

> how hard is it to just use consistent indentation

It's pretty annoying when you don't have access to an IDE or decent editor.

Post reply on HN