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

301–310 of 351 posts

Re: Why are we templating YAML?

#301

Post by imtringued »

skywhopper wrote: post #164
ilovetux wrote: post #72

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 like YAML but it has some minor quirks and it feels overused in domains in which it simply doesn't make sense to use YAML. I can think of ansible or complex dynamic configurations that depend on external values as mentioned in the article. If simple merging of a base file + dev, staging, prod files isn't enough for the task at hand then YAML is a bad fit.

Re: Why are we templating YAML?

#302

Post by Gabriel439 »

leg100 wrote: post #245
ff_ wrote: post #198

Earlier quoted context omitted.

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 exac…

I don't get the problem with using a turing complete language to generate configuration. There's nothing wrong with maintaining and refactoring a program, that's a natural process for any program. If you don't want an infinite loop, don't write one, as you wouldn't in any other program. You can choose as much or as little abstraction as you so wish. Give me a real language any day over dhall or jsonnet.

This explains the disadvantages of using a general-purpose programming language as a configuration language:

https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarant...

Re: Why are we templating YAML?

#303

Post by marcosdumay »

hannasanarion wrote: post #108
krferriter wrote: post #86

Earlier quoted context omitted.

Yeah this is a huge selling point of YAML. JSON should have comments added to the spec. The other benefit to YAML is human readability, which is usually better in YAML compared to JSON. A specific glaring example of this is when there are long string-literal snippets inside the document, in YAML this is massively more readable than in JSON.

JSON shouldn't have comments added to the spec, because people shouldn't be trying to read or write JSON. It's an application interchange language, meant to be written and read by machines. YAML is a markup language, meant to be written and read by people. Ever notice how most YAML libraries don't even have a "dump" function?

Hum... We have a bad historic of success in deciding that this or that stuff is for machine consumption only.

Re: Why are we templating YAML?

#304

Post by ithkuil »

leg100 wrote: post #259
ithkuil wrote: post #250

Earlier quoted context omitted.

FWIW jsonnet is a "real" language. It's a dynamically typed, lazily evaluated purely functional programming language).

Fair enough. I should have said "general purpose language" rather than "real", which makes for flame-bait.

I once built a mandelbrot fractal renderer which emitted a data-URL encoded PNG string to stdout in BCL (a spiritual predecessor of Jsonnet @ Google).

Yeah, I know what you mean. It lacks generic input/output, you cannot read write arbitrary files and perform arbitrary network requests etc.

I do like that restriction in the context of managing configuration systems, because it allows you to build hermetic evaluations.

With kubecfg we added the ability to import from URLs, which I wish was available out of the box in jsonnet.

Re: Why are we templating YAML?

#305

Post by Gabriel439 »

merijnv wrote: post #236
Cyph0n wrote: post #106

Earlier quoted context omitted.

What is up with the strange comma positioning? I assume that’s just a stylistic choice?

Having prefixed commas is a rather common style in the Haskell community, because it ends up nicely matching open/closing brackets/braces and lining things up. Since the author of Dhall comes from the Haskell community, he's kept this style.

Author here: This is correct. I'm just borrowing a Haskell convention. Also, I like this convention because it leads to vertical alignment of commas.

Re: Why are we templating YAML?

#306

Post by devxpy »

sametmax wrote: post #237
Scarblac wrote: post #225

Earlier quoted context omitted.

In defence of Django, the way settings.py works has been very stable for the entire lifetime of Django. It may have its problems (I don't have many issues with it) but it doesn't seem to have this problem of attracting ever more layers of abstraction on top of it. It works.

Actually, I think settings.py is not a bad idea, but it's half backed. There should have a schema checking the setting file. There should have a better way to extend settings, and make different settings according to context, such as prod, staging or dev. There should be a linter avoiding stupid mistakes like missing a coma in a tuple, resulting in string concatenation. There should be variables giving you basic stuf…

There is already a mechanism to validate the settings.py file inside django.

The different context stuff can be handled by using env vars, and a nice python wrapper, like python-decouple.

Re: Why are we templating YAML?

#307

Post by alxarch »

Over the last week I created a tool processing YAML and JSON files using Jsonnet. It's called [ycat](https://github.com/alxarch/ycat) and is inspired by `jq` but uses Jsonnet for processing. It can also be used just as `cat` to concatenate JSON/YAML files. It's still young but very usefull, especially for handling complex kubernetes configurations.

Re: Why are we templating YAML?

#308

Post by sametmax »

devxpy wrote: post #306
sametmax wrote: post #237

Earlier quoted context omitted.

Actually, I think settings.py is not a bad idea, but it's half backed. There should have a schema checking the setting file. There should have a better way to extend settings, and make different settings according to context, such as prod, staging or dev. There should be a linter avoiding stupid mistakes like missing a coma in a tuple, resulting in string concatenation. There should be variables giving you basic stuf…

There is already a mechanism to validate the settings.py file inside django. The different context stuff can be handled by using env vars, and a nice python wrapper, like python-decouple.

> There is already a mechanism to validate the settings.py file inside django.

It's not exposed, but it's very limited.

> The different context stuff can be handled by using env vars, and a nice python wrapper, like python-decouple.

It's just one of the way to do it. Go to a new project, they use a different way. The main benefit of Django is the fact that a Django project is well integrated, and you find similar conventions and structure from project to project, allowing to reuse the skill you learned and build an ecosystem of pluggable app.

Re: Why are we templating YAML?

#309

Post by macspoofing »

eadmund wrote: post #285
macspoofing wrote: post #62

Earlier quoted context omitted.

>it's as bad or worse than XML for config files XML works very well for config files. It's schema-optional (but is there), well-specified, human-readable, has plethora of supporting technologies (making things like templating easy), and is well supported by every language. At the very least it is way better than JSON.

There's absolutely no way that this (copied from https://github.com/akeeba/fof/wiki/The-XML-configuration-fil... ): items ABCD123456 HTTPBasicAuth_TOTP,QueryString_TOTP published foo,bar,baz browse core.manage 3 is at all preferable to this: (fof (common (container (component-namespace "MyCompany\\MyApplication")) (dispatcher (default-view items)) (authentication (totp-key ABCD123456) (authentication-methods (http-ba…

You changed the model when you adapted the xml to lisp. You decided that some tags are unnecessary, dropped some attributes and assumed others are merely different types of child nodes - and now your sample doesn't actually have the same semantic meaning as the XML example. You also removed some comments. Was all this done to emphasis how much cleaner a lisp alternative would be? If we're playing this game, you can actually simplify the XML configuration file as well. If you attempted to capture everything that the XML does, it would make your lisp sample much more ugly.

Anyway, to each his own, but I think XML holds up very well and I do find it more readable and easier to work with that your lisp example.

I also never said XML is the best configuration format. For simple configurations a simple property file is by far the best option. For anything complicated (as in your example) XML does a great job. To contrast, JSON would fall flat on its face with this. Not to mention the fact XML parsing is typically part of the standard library of most programming language and most people are familiar with it.

Re: Why are we templating YAML?

#310

Post by macspoofing »

guitarbill wrote: post #70
macspoofing wrote: post #62

Earlier quoted context omitted.

>it's as bad or worse than XML for config files XML works very well for config files. It's schema-optional (but is there), well-specified, human-readable, has plethora of supporting technologies (making things like templating easy), and is well supported by every language. At the very least it is way better than JSON.

> human-readable technically yes, practically maybe not so much, especially with e.g. CDATA sections

If we're talking about a human-editable configuration file, then yes, it will be quite human-readable.

Machine generated XML can be noisy but the target for those are other machines, and the extra context is there for a reason.

You can certainly make XML as obtuse and complex as you want.

Post reply on HN