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

Why are we templating YAML? (2019)

leebriggs.co.uk

Post reply on HN
Print view View original

351–360 of 667 posts

Re: Why are we templating YAML? (2019)

#351

Post by usrbinbash »

eviks wrote: post #338
usrbinbash wrote: post #326

The problem is very specifically the fact that YAML, as a config language, sucks. I have no idea why people started using it. "bUt jSOn dOeSn'T HaVe cOmMenTS" ... oh gimme a break! You want a comment in JSON? { "//": "This is a comment explaining key1.", "key1": "value1", "//": "This is a comment explaining key2.", "key2": "value2" } There. Not so hard. Writing a config parser that just ignores all keys starting with…

That ugly child doesn't cut it, these are the comments people want: key1=value1 # this is a proper key1 comment, if you move a line, it stays with key1 key2=value2 # it also doesn't break the table # and you don't need to write a config parser # nor modify a syntax highlighter # nor make sure other people use your comment style

If people absolutely want those, they can use TOML, which supports single line and inline comments.

Given a choice, I'd even opt XML over YAML.

Re: Why are we templating YAML? (2019)

#352

Post by kadoban »

wkat4242 wrote: post #117
torginus wrote: post #109

Earlier quoted context omitted.

Dunno, to me YAML is the python of markup languages. YAML is decent at handling things like nesting and arrays, while TOML sucks at it. I don't dislike YAML that much. That being said, we knew since the dawn of C macros that templating languages which are not aware of syntax, are AWFUL. Likewise, writing Helm charts (the place I encountered YAML templating) is just horrible, but would be so much nicer is templates re…

The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't under…

> And forbidding it makes a one-keystroke action a two or four one.

This isn't a tabs or spaces issue. This is a "your editor is bad or configured wrong" issue.

Re: Why are we templating YAML? (2019)

#353

Post by mejutoco »

wkat4242 wrote: post #117
torginus wrote: post #109

Earlier quoted context omitted.

Dunno, to me YAML is the python of markup languages. YAML is decent at handling things like nesting and arrays, while TOML sucks at it. I don't dislike YAML that much. That being said, we knew since the dawn of C macros that templating languages which are not aware of syntax, are AWFUL. Likewise, writing Helm charts (the place I encountered YAML templating) is just horrible, but would be so much nicer is templates re…

The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't under…

Every editor I know can enter n spaces when pressing tab. That might solve your concern.

Re: Why are we templating YAML? (2019)

#354

Post by angarg12 »

Draiken wrote: post #72

I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…

I'm very happy using Typescript to templatize JSON. You can define a template as a class, compose them if needed, and when you are done, just write an object to a file.

Re: Why are we templating YAML? (2019)

#355

Post by ithkuil »

worldsayshi wrote: post #152
ithkuil wrote: post #146

Earlier quoted context omitted.

I love the idea of keeping it simple and I do try to use kustomize or even plain yaml as installation method as much as possible. But in practice when managing large systems you inevitably end up benefiting from templating

I've begun thinking that if you start thinking about templating you might be better off building an operator. Operators aren't as well understood and documented. But in my mind an operator is just a pod or deployment that creates on demand resources using the k8s api.

oh yeah; operators are great and sometimes they are necessary.

On the other hand, most operators I've seen are just k8s manifest templates implemented in Go.

I often end up preferring using Jsonnet to deal with that instead of doing the same stuff in Go.

Jsonnet is much more close to the underlying datamodel (the k8s manifest Json/Yaml document) and comes with some useful functionality out of the box, such "overlays".

It has downsides too! It's untyped, debugging tools are lacking, people are unfamiliar with it and don't care to learn it. So I totally get why one would entertain the possibility of writing your "templates" using a better language.

However, an operator is often too much freedom. It's not just using Go or Rust or Typescript to "generate" some Json manifests, but it also contains the code to interact with the API server, setup watches, and reactions etc.

I often wish there was a better way to separate those two concerns

I'm a fan of metacontroller [1], which is a tool that allows you to write operators without actually writing a lot of imperative code that interacts with the k8s API, but instead just provide a general JSON->JSON transformer, which you could write in any langue (Go, Python, Rust, Javascript, .... and also Jsonnet if you want).

I recently implemented something similar but much tailored to just "installing" stuff, called Kubit. An OCI artifact contains some abitrary tarball (generally containing some template sources) and a reference to a docker image containing an "engine" and runs the engine with your provided tarball + some parameters passed in a CRD. The OCI artifact could contain a helm chart and the template engine could contain the helm binary, or the template engine could be kubecfg and the OCI artifact could contain a bunch of jsonnet files. Or you could write your own stuff in python or typescript. The kubit operator then just runs your code, gathers the output and applies with with kubectl apply-set.

1. https://metacontroller.github.io/metacontroller/intro.html

2. https://github.com/kubecfg/kubit

Re: Why are we templating YAML? (2019)

#356

Post by kimbernator »

Draiken wrote: post #72

I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…

I once took a job that involved managing Ansible playbooks for an absolutely massive number of servers that would run them semi-regularly for things like bootstrapping and patching. I had used Chef before for a similar task, and I loved it because it's just ruby and I could easily define any logic I wanted while using loops and proper variables.

I understand that Ansible was designed for non-programmers, but there is no worse hell for someone who is actually familiar with basic programming than being confined to the hyper-verbose nonsense that is Jinja templating of Ansible playbooks when you need to have a lot of conditional tasks and loops.

Re: Why are we templating YAML? (2019)

#357

Post by basil-rash »

sakjur wrote: post #252
foldr wrote: post #74

Earlier quoted context omitted.

Or more precisely, its country code 'NO' is false. I don't think there are any YAML parsers that parse the literal string 'Norway' as false.

The YAML 1.2 spec removed “no” as a synonym for false. That arguably just made that entire problem worse, and even though it’s been almost 15 years YAML 1.1 is still the commonly used variant.

Ah, that explains why I couldn’t find any online YAML->JSON converters that would demonstrate this flaw when it came up a few weeks ago.

So now we have the same language that parses the same document subtly differently depending on what version you use. Hooray?

Re: Why are we templating YAML? (2019)

#358

Post by solardev »

swader999 wrote: post #314
fatnoah wrote: post #295

Earlier quoted context omitted.

At one of my internships in the 90's, a developer I worked with solved the problem by never indenting. Every single line of code started at column 1.

Why even use more than one line?

Why not just make everything whitespace? Give both tabs and spaces their rightful place! https://en.wikipedia.org/wiki/Whitespace_%28programming_lang...

Re: Why are we templating YAML? (2019)

#359

Post by runlaszlorun »

jalapenos wrote: post #274
armchairhacker wrote: post #38

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…

I guess the real mystery is why so many tech types speak like a infant having a tantrum, about some esoteric trivia, and then have hordes of their kind come and vigorously head-knod it, and all involved think virtue is being done. People started using things like YAML, obviously, because it reads closer to natural language. It's like a nested bullet list, which everyone can easily read. Readability is important to pe…

> I guess the real mystery is why so many tech types speak like a infant having a tantrum, about some esoteric trivia, and then have hordes of their kind come and vigorously head-knod it, and all involved think virtue is being done.

Ha, great line. And you caught me mid-tantrum and mid-head nod. :)

Re: Why are we templating YAML? (2019)

#360

Post by WorldMaker »

jampekka wrote: post #312
Two9A wrote: post #263

Earlier quoted context omitted.

And I've been using vim exclusively for north of fifteen years with Tab replacement, never had a problem with the editor getting confused about what happens with spaces when I hit Tab. Some detail about the corner cases you've run into would be great, if they're happening constantly I can see how it would be a bugbear.

For example with vim (debian) defaults, if you happen to have a 2-space indented Python (the first two spaces are for HN formatting, the first if should start at zero indent): if True: # Two space indent And continue to add another if block in that, the autoindent will give you four spaces: if True: # Two space indent if True: # Four space autoindent And if you make a new line after the last row there and hit a backs…

As with most things in vim, it is definitely manageable in settings such as tw=2 (tab width) and sts=2 (soft tab stop). This is why a lot of older Python files, in particular, are littered with vim modelines with settings like these.

The nice modern twist is .editorconfig files and the plugins that support them including for vim. You can use those to set such standard language-specific config concerns in a general way for an entire "workspace" for every editor that supports or has a plugin that supports .editorconfig.

Post reply on HN