I learned to stop worrying and don't really care, I'll happily use xml, json, yaml or toml . To me, it doesn't really make a lot of difference, and yes, there are a bunch of reasons why various formats have different advantages, but it really doesn't take much of my life, things don't really go wrong with any of them, and while I have a preference, pragmatically, I just don't care.
I stopped worrying and in most cases just write configs for my tools in python. Then you can just import/exec it and you're done.
I can use all the operations/primitives I already know in Python: string interpolation & operations, loops, Pathlib, imports etc.
I can use mypy and all the other existing linting tools to make sure my configuration is correct without having to write a custom linter (and basically reimplement 10% of mypy).<p>Shameless plug if you wanna read a longer analysis: <a href="https://beepb00p.xyz/configs-suck.html" rel="nofollow">https://beepb00p.xyz/configs-suck.html</a><p>A great example is pyinfra <a href="https://github.com/Fizzadar/pyinfra#readme" rel="nofollow">https://github.com/Fizzadar/pyinfra#readme</a> Think Ansible but instead of YAML you write Python. It provides a set of primitives/DSL and some rules you need to adhere to, but otherwise you just write regular python code.
My experience is that with both YAML and XML, the key is to have a well-designed schema. The problem isn't YAML or XML, but abuses of them. Most of the criticisms come from badly-designed schemas. HTML 2.0 was very usable, and there are other XML schemas which are nice.<p>There are a few keys:<p>1. Don't reinvent constructs. If your XML looks like <element name="foo"><attribute key="bar" value="biff" /> </element>, you've got a problem. It should be <foo bar="biff"/><p>2. Provide reasonable defaults. Everything should be optional.<p>3. Break up files into manageable chunks<p>I wish everything in /etc/ used a common format, like YAML, or a small set of common formats.<p>I also wish for good configuration libraries, which handled:<p>- Parsing / validating YAML config files, command line parameters, environment variables, database overrides, defaults, etc.<p>- Printing pretty error messages<p>- Worked in a few languages (Python, JavaScript, and perhaps C)<p>- Guided developers towards sane designs.<p>Also, if you're putting objects in XML, documents in YAML, or strictly tabular data in either, you're probably doing something wrong.<p>- YAML: Configuration files, objects<p>- XML: Documents<p>- CSV/TSV/TSVX: Tabular data
CUE is the most interesting language in this space right now <a href="https://cuelang.org/" rel="nofollow">https://cuelang.org/</a>
I've been using YAML for years and years, and will always hate it. I understand why it exists, but I still can't stand it, nor do I have a desire to force myself to love it. I just generally hate white-space defined scopes. I love Python, but still hate it has white-space defined scopes, too!<p>You can't make me love YAML!<p>(but I'll still use it and put my hatred to the side!)
Bah, a clickbaity title that amounts to:<p>- YAML is fine when you can use it for last mile configuration and don't have to use it for everything else<p>Well, I agree. Take Helm, for example. values.yaml is a perfectly nice configuration file that you can even enjoy editing. The chart itself is an abomination of endless boilerplate (not Helm's fault, but inherited from k8s) and the worst possible templating mechanism bolted onto it (totally Helm's fault).
> We all know one of those people who’ll tell you that the answer to all infrastructure problems is a bunch of EC2 instances, a golden AMI and a load balancer. Those people might be right, but if take a look at your infrastructure right now, could you solve the problems in your organization by going back to building AMIs and sticking them behind a load balancer? Even if you can, do you really want to? No, I thought not.<p>Other than the slow pace to bake and test golden images I still prefer this approach. It is simple and a proven design and easy to build-out on every single cloud provider.<p>I might be biased tho, this is how we manage the host's for our several thousand Kubernetes clusters. I'm just kind of used to it.
I've been thinking about what make a good language for configuration files, and the conclusion I've come to is that it ought to have:<p>- Local variables<p>- Pure functions with basic math and string manipulation capabilities<p>Possibly with an extended version that also has:<p>- Input variables (that <i>must</i> be provided by the code reading the file)<p>- Exportable functions that are callable by the host code<p>This extended version would be perfect for use cases like defining CI pipelines.<p>A language that did this but was otherwise simple and allowed no access to the host system, and had widely available library support across most common languages would be just awesome.
I'm on my phone right now but maybe one if you can double check: since YAML is a superset of JSON you can parse JSON with a YAML parser right? Does that mean you can add YAML comments to JSON and parse the JSON with the YAML parser, to get JSON-with-comments?
The thing that most frustrates me about YAML is probably not the language itself but the poor IDE and GitHub tooling I have been using. Trying to figure out the hierarchy of a key in a YAML file (local or GH) is incredibly frustrating. With formats like JSON at least (if nothing else) I can just open the file in vi, find the next close-curly and hit % to find the parent -- easy.<p>Significant whitespace is also a problem but I think that war has been lost.
I like the approach in Google: everything is a protobuf message including a config.<p>A couple benefits: 1) all fields are documented and strongly typed, with backward and forward compatibility (old binary + new config, new binary+ old config works). 2) you can use any language to generate the config, simply specify your proto-generator binary as dependency. 3) if your config is simple enough and willing to lose some backward/forward compatibility, a text proto file is perfectly human readable/writable.
> It might just be personal preference here, but I look at that thing and shudder. Can you imagine authoring that? Maintaining it?<p>Isn't the problem more the tooling than the configuration language specification? Can you imagine authoring office documents by hand? Or maintaining them?<p>My text editor, KeenWrite, allows users to reference YAML variables as paths while editing documents. The editor includes a collapsible tree view of the variables, which makes navigation and maintenance a breeze.<p><a href="https://i.ibb.co/qp0vj1Q/yaml-editor.png" rel="nofollow">https://i.ibb.co/qp0vj1Q/yaml-editor.png</a><p>Also, when inserting a variable into the document, the YAML tree expands automatically to the location the variable is defined. From the end user perspective, the data format is irrelevant.<p>Here's an example that produces a user-friendly UI for a JSON schema:<p><a href="https://json-editor.github.io/json-editor/" rel="nofollow">https://json-editor.github.io/json-editor/</a>
This problem it is not the format itself. The problem (IMHO) is with how users use it. I see huge issue of users looking at YAML as a plan text document without regard of actual document structure.
Here is example of widely used blatant misuse in popular tool - Helm Charts - allows to create Jinja templates for YAML documents totaling ignoring structure of the documents - as a result users have tools to control the number of tabs/spaces but no they to work with document structure (like injecting element under certain path or validating if document structure is correct).
This is such a shame and loss to DevOps community that such as widely used tool as helm chart continue teaching new users of bad habits.
Honestly I don't... YAML is more compact but still hyper verbose and hyper rigid respect of XML witch is the same respects the older SGML. The old new trend is going through real programming languages instead of dedicated data-formats, from those who use Python or DHall or those who prefer lisp to be in a more civilized land...<p>Just compare Ansible/Salt YAML+python (because you can't do anything YAML-only) to Guix System, just see k*s YAML or Home Assistant ones: they are horrible to manage by a human. They are not much effective respect of anything else for a machine.<p>Long story short IMVHO it's about time to recognize that the old "data and language together" is the way to go, erasing common DSLs/formats/parsers etc.
Author's examples of „good” use of YAML still would be more readable as Lua[1] or JS code. Return one table/object and call two functions instead of clunky YAML stuff like Fn::Invoke.<p>[1]: <a href="http://ix.io/3XTk" rel="nofollow">http://ix.io/3XTk</a>
So the idea is to define a component in a general language for great configurability, and then make it possible to consume / instantiate it with YAML.<p>What if the way you wrote the component does not allow some sort of dynamic config you need through YAML. Now you are working in two separate files and two different languages trying to make a change. Things almost get worse when the writer of the component and the consumer of the component are different people. Either massive horrible cludges happen to the YAML, or a weird back and forth needs to happen.
I just find that YAML doesn't improve anything over JSON.<p>Having recently migrated from cloudformation to terraform on a project the use of HCL is wonderful in comparison and when I'm all ready to commit I just type terraform fmt and everything is aligned properly. Considering it's just as trivial to do this in any JSON prettifier...I don't understand the need for yaml besides pure asthetics which is why you either love it or hate it, because it doesn't help or hurt it just annoys you or it doesn't.
Blah. Right now at work I'm using YAML with HAML ruby files and its... Not great. Really difficult to search for in our code base. Its hard to tell what is routing where due to helper methods often pointing to certain YAML files based on certain conditions.<p>I don't have a better solution but it just feels needlessly complex for text.