For anyone struggling with Helm YAML syntax errors in their day job, I shamelessly advertise my browser-based debug tool Helm Playground:
https://helm-playground.com/ - https://github.com/shipmight/helm-playground
Why are we templating YAML? (2019)
251–260 of 667 posts
Re: Why are we templating YAML? (2019)
#252Earlier quoted context omitted.
> Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)? Norway is also "False".
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.
Re: Why are we templating YAML? (2019)
#253To 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 XML and JSON are too verbose. But YAML is so far in the opposite direction, (...)
YAML is a far better format in terms of being human readable and editable, and supports features such as node labels and repeated nodes that turn into killer features when onboarding YAML parsers into applications.
Re: Why are we templating YAML? (2019)
#254Earlier quoted context omitted.
People balk at XML, but its verbosity plus DTD allows it to pull tricks which you can't do on other things. Well everything has its place, but XML is I think very well suited where you need to serialize complex things to a readable file, and verify it while being it's written and read back .
XML + DTD + XMLSchema had things we're still figuring out to do with YAML ja JSON You could easily generate an UI based on just the DTD and Schema that could be used to fill a perfectly valid XML file. Validating incoming XML was a breeze, just give it to the validator class along with the DTD and Schema and boom, done.
> Validating incoming XML was a breeze, just give it to the validator class along with the DTD and Schema and boom, done.
See the boom? It's boomer tech. We can't have old, boomer tech in 2024.
Jokes aside, I wish people spent the time to understand the technologies before disliking them and blindly implementing a different, inferior one.
Re: Why are we templating YAML? (2019)
#255So true. I abhor yaml. It’s impossible to know correct indentation without a plugin that shows it which isn’t available in many cases where you edit yaml. It’s whitespace sensitive. The data types are not obvious. It’s just all a round bad
I love json. It’s explicit and easy to read. We should just be using json for everything that needs to be human readable.
Re: Why are we templating YAML? (2019)
#256Earlier quoted context omitted.
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. You can’t be serious
I prefer to keep my json to one line without white spaces, saves on disk space.
Re: Why are we templating YAML? (2019)
#257Earlier quoted context omitted.
For complex environments like those discussed in the article, there’s unavoidably complicated logic. Code is a good place for logic to live. Compared to yaml, code is more testable, readable and expressible. I should’ve restricted my original comment to the kind of situation in the article where different configs are created for various regions and test environments with optional values. Totally agree configs are use…
Restricting config to static values removes quite a bit of the value of config, in my opinion. Yes, logic should live in code, but very often that logic needs to behave differently depending on some piece of (inherently variable, not static) configuration. Random examples (written from the perspective of personified code): - How many threads should I use? - On which port should I serve metrics? - Which retry strategy…
By "more static", I meant items with only a handful of variations.
If you're using one port for dev & another for prod I reckon it's best to have it in config.
But if you're port is varying by image, region, dev/test/prod status and has exceptions for customers using your app on prem then keeping all that logic in code may be easier.
Re: Why are we templating YAML? (2019)
#258Worse yet, in some places (CI/CD) YAML becomes nearly a programming language. A very verbose, unintuitive, badly specified and vendor-specific one as well.
It's pretty much repeating the mistake of early 2010s Java, where the entire application frequently was glued together by enormous ball of XML that configured all the dependency injection.
It had the familiar properties of (despite DTDs and XML validation) often blowing up late, and providing error messages that were difficult to interpret.
At the time a lot of the frustration was aimed at XML, but the mid 2020s YAML hell shows us that the problem was never the markup language.
Re: Why are we templating YAML? (2019)
#259Earlier quoted context omitted.
> it was an advancement That was certainly the selling point. I never saw any advancements in it - the features were aesthetic syntactic sugar.
Coffeescript came with spreads and destructuring, and added string interpolation, just to name a few things. It also added classes and inheritance, the ?. operator, . I suppose you could argue those are just synctatic sugar because they compiled down to ES5, in the same way you can argue that any programming language is synctatic sugar over raw machine code. I may disagree (_heavily_) with the Pythonesque syntax Coff…
In addition to this: ruby-like classes and "sane"/expected handling of this using fat arrow functions. I've worked with a few developers at the time that considered themselves pure backend/rails developers and didn't (bother to) grok the details around the way this worked in JS.
I distinctly remember lots of var that = this; in JS code back then, which wasn't required anymore when using CoffeScript.
Re: Why are we templating YAML? (2019)
#260Earlier quoted context omitted.
> And forbidding it makes a one-keystroke action a two or four one. You can’t be serious
I prefer to keep my json to one line without white spaces, saves on disk space.
JSON formatting is less important because most apps that deal with it come with good “beautify”, “sort”, “remove all formatting white space” functions in the editor