I can't help wonder how much better YAML would've been with minimal delimiters instead of significant-whitespace. The big feature (X/YA)ML has over JSON is distinction between properties and children; which I think is pretty cool for many use-cases. Lack of comments is also a big limitation of JSON, and of course there's the huge legacy ecosystem behind XML. But I've never seen significant whitespace be a good thing; this alone makes YAML decidedly not "human readable", speaking as someone who doesn't work with it very often.
In Defense of YAML
91–100 of 173 posts
Re: In Defense of YAML
#92Earlier quoted context omitted.
Ansible deserves some credit at least. It tried to avoid the pitfalls Chef and Puppet fell into, which is having a DSL that allows arbitrary logic, i.e. basically just a Ruby script. These become horrible to trace and debug. Ansible only allowed conditionals or loop constructs in some well-defined places, which actually does help when trying to comprehend Ansible playbooks. (Although one might still argue a strict DS…
I feel like there is a large gap between shell scripts and Ansible. If we draw a line, you end up with something like this, with each option bringing more power, but also complexity with it. Bash/Make => ? => Ansible => Chef/Puppet/Salt => CFEngine There's a big jump in complexity from Bash/Make to Ansible. This is a place where Python or Ruby would make a lot of sense but without all the dsl/yaml/declarative nonsens…
It's unfortunate that "shell scripts" represent the imperative solution. Shell scripting is loaded with incidental complexity and footguns that other scripting languages (like Starlark) lack. The latter would be entirely appropriate for this sort of advanced configuration.
Re: In Defense of YAML
#93You can actually use Python as a configuration file pretty well, if you need more complicated logic and macros. Otherwise, sticking to a toml or ini file is my preference.
Agreed, hopefully ini files have lost the Windows stigma enough to be used everywhere.
Re: In Defense of YAML
#94While we're writing the wrongs of badly specified interfaces, can we please kill this stupid obsession with "writing code" to get work done? Code is buggy . It's difficult to write well, you have to write 10,000 tests for it, you have to have a testing framework, complex procedures to move it through pipelines and roll it back and version control it and debug it and maintain it and deploy it. It's annoying. I don't w…
So while obviously a bit data UI wise are CPAN's config script and/or the "make menuconfig" script for compiling a Linux kernel good examples of what you're talking about?
While I haven't run menuconfig since the 90's I find myself setting up CPAN on just about every server I manage. Although a bit dated like I said above it's still very easy to use and provides clear instructions on why you should or should not choose certain options based on the environment you are setting up.
Just wondering if these are good examples or not. If not, do you have any other examples of good config programs you can point to?
Re: In Defense of YAML
#95The configuration method for the Gunicorn server (http://docs.gunicorn.org/en/stable/configure.html#configurat...) would be a great example to follow. Configuration files are just Python modules. You can specify the number of workers and set log file locations with the following:
from multiprocessing import cpu_count
def max_workers():
return cpu_count() * 2 + 1
workers = max_workers()
errorlog = "/var/www/lcfs/logs/error_logs.log"
accesslog = "/var/www/lcfs/logs/access_logs.log"Re: In Defense of YAML
#96> This is not structured data. This is programming masquerading as configuration I find myself expressing this same opinion to people on a frequent basis. See ansible for another big example. Ansible has a try/catch equivalent in yaml [0]! Unfortunately, YAML is more or less a lowest common denominator for these sorts of interactions - being usable from any language is a really big boon. Would love to see the world a…
Ansible deserves some credit at least. It tried to avoid the pitfalls Chef and Puppet fell into, which is having a DSL that allows arbitrary logic, i.e. basically just a Ruby script. These become horrible to trace and debug. Ansible only allowed conditionals or loop constructs in some well-defined places, which actually does help when trying to comprehend Ansible playbooks. (Although one might still argue a strict DS…
From my perspective--as somebody who slings this stuff a lot--what you describe as a "pitfall" is what I describe as "how to make things work."
I don't find that Chef cookbooks are all that onerous to debug at all. Cleanly-written Ruby (and you can write Chef cookbooks in very clean Ruby, it really isn't that big of an ask) isn't hard to trace and in the extreme case--and this has happened twice in my career--I just install Pry and drop a breakpoint into the Chef cookbook, then proceed to poke around, isolate the problem, and move on with my day.
This, contrasted with Ansible's flinging around of Jinja templates and trying to turn YAML into a bad programming language, is a relief, and when I was a consultant I charged a premium for Ansible first because it frustrated me but second because it was generally harder for me to find out what was actually going on due to the verbosity, the commonplace copy-pasting, the relatively poor method of inventorying, and the "strap in, it's gonna get bad" anytime somebody decided to break out of the YAML mines and go write their own module.
There remains a very awkward sysadmin/developer divide in the devops world, and I think that criticisms like the one you describe generally tend to hail from the former. As a developer whose output on occasion happens to be configured systems (when it isn't web pages, etc.), I'd rather a predictable programming environment over a "configuration language" every day (and it's one of the reasons I really wish that Noah's attempt to turn cookbooks into gems paid off; having them be a completely separate artifact from a Ruby gem is just silly).
Re: In Defense of YAML
#97A substantial part of the french social and tax system is being coded as free software. One of the teams writes the source code in YAML. It's not a programming language, but rather a specification for calculable parts of the law. A JS programm then generates Typeform-like simulators, a node library, and an online interactive documentation (it is now compulsory for french administrations to explain their algorithms).…
Interesting. I just hope the resulting software is less buggy than the one for army wages...
Re: In Defense of YAML
#98Earlier quoted context omitted.
I don't understand why people use a markup language when they need a programming language. I mean, sure, you can convert one into the other syntax-wise, both form trees, but what do you gain?
Because the tools only support markup languages, so we have to use stuff like Jinja or go templates to create those.
We don't have to--you can generate the markup language with a scripting language and end up with something that is quite a lot cleaner. I've been toying around with Starlark as a yaml generator for Docker Compose, CloudFormation, and Kubernetes. This ends up working out a lot more nicely in practice than Helm's templating solution or CloudFormation's nested stacks.
Re: In Defense of YAML
#99Recently been working on a rails app and been forced to use nano for editing one a remote server and it's now that I really see the niceness of YAML. I always like YAML with ruby but I think a lot of the great features are subtle and hard to appreciate. Inheritance! What a great idea for a configuration language. Greatly missed in JSON.
Re: In Defense of YAML
#100A substantial part of the french social and tax system is being coded as free software. One of the teams writes the source code in YAML. It's not a programming language, but rather a specification for calculable parts of the law. A JS programm then generates Typeform-like simulators, a node library, and an online interactive documentation (it is now compulsory for french administrations to explain their algorithms).…
Interesting. I just hope the resulting software is less buggy than the one for army wages...
Sorry, I should have noted that for the moment it is only a simplified implementation of the latest laws.
Bugs arise when you're forced to integrate rules that change over time.