Yaml is the language nobody needed. All we wanted was a better JSON format that supports comments and doesn’t crash with an extra comma as the end of a list, eg: [1,2,3,]
As someone who has tried to parse this crazypants as a side-effect of the old 1Password.opvault, please don't. The idea that one has to //key[text()=="firstname"]/following-sibling::string/text() because they're not nested they're siblings. Insanity
Trailing commas for sure, but I buy the argument that comments would be used to sneak in arbitrary directives and break interoperability. In fact, I’d like to see a less featureful JSON where everything is strings. Trivial parsing, leave interpretation up to the receiver.
For a configuration language, comments are absolutely crucial. You want to be able to say "# This option is set because <so-and-so>" to explain why you are configuring it this way to the next person that reads the code (or you, in the future).
If the price to pay is that there is some risk some dummy might start parsing the comments as code, so be it. This is not a really a problem in "regular" programming languages, I don't see why it would be in a configuration language.
I don’t think the Linux one is that stupid, but it might be me.
It’s not a “magic comment” because it doesn’t depend on the runtime. It specifies an interpreter to use, regardless of the language of the file.
Eg you can use #!/usr/bin/python for a Python script. I don’t find it worse than the existing alternative of making the file name magic and finding and interpreter based on that.
It's a comment ignored by the interpreter (bash, python, whatever).
The kernel just says "Hey! You can't execute a text file, you weirdo! I'll just read the very first line of the text file and if it happens to be a comment that points to another executable, I'll run that and pass it this file."
Comments by themselves provide enough value to justify their supports.
Plus non standard stuff is not a valid argument. As there are many tools which support non standard behaviour, because useful features like comment are considered non standard
In most cases Yaml is bizarre kind of DSL with tricky way of API interaction. For instance - I don't understand why exactly the same Ansible API isn't just python library?
For the same reason any DSL exists: because the programming representation is a lot more verbose than the DSL, due to the computers not currently honoring the "you know what I meant" flag
#!/usr/bin/env python3
"""A made up example of the line noise"""
from ansible import *
def main():
hosts = ["localhost"]
for h in hosts:
run_one_host(h)
def run_one_host(inventory_hostname: str):
connection = ansible.builtin.ssh(inventory_hostname)
print("sniff out the machine's os")
host_vars = ansible.builtin.setup(gather_subset="os", connection)
if host_vars["distribution"] == "ubuntu":
dest = "/etc/apt"
else ...
dest = "/etc/something else"
print("do something awesome")
copy_ok = ansible.builtin.copy(src="./some_file", dest=dest, connection)
...
That said, I can't readily imagine why you couldn't do exactly what you said because the AnsibleModule[1] contract is JSON over stdin/stdout (and one can write Ansible modules in any programming language[2] - they just default to Python)
python (as much as I personally dislike the language itself) has clean syntax for sets, dicts and arrays. Which are the data structures you use in a playbook. Ansible as python instead of yaml can be made to look very similar to current playbooks. But saner. And easier to script.
This format is unreadable on mobile, it keeps opening up my keyboard and scrolling up a bit when it does.
I understand and appreciate the "why" of the format, but this also could have been a non-editable "editor-like" presentation and achieved the same result.
Yeah theres some problem, but reading a multiline code block (like github actions bash script) as an indent-escaped string is so much better than having to understand crazy triple-escaped characters like "sed \"\\\\\\"name1\\\\\\\"\""
This is the same debate folks have between Maven and Gradle: do you want CI code to be able to do *anything* that Python or Node can do, or do you want well defined knobs people can turn. If nothing else, it makes code reviews for CI way less drama than trying to use some bespoke dsl-in-python that re-implements {job: {steps: [{run: ...}]}} in a less legible way
Yeah. My experience has often been that you end up with a task that is very easy and familiar to write in say Bash, that you then have to solve a puzzle to write in Ansible/Puppet/whatever. Which feels exactly like what you're saying: a DSL re-implementing something else in a less legible way.
I guess it's like anything: for the right task, the right tool works well. But invariably, a tool will eventually be pushed into use for the wrong task.
you only think until you have to extract some information from it. "Here is a dir full of CI job definitions, find all the ones which require extra permissions" - trivial in yaml or json or toml, could be hard to impossible for Python/nodejs.
or "I am doing ci job frontend, for each job I need to get a list of inputs it takes and their description, but without doing full code checkout" - good luck doing this if your jobs are in python/nodejs.
(to be fair, there are programming languages that are also severely limited and can be evaluated mostly safely, like Starlark, but I don't think they'd match your definition)
I will die on the hill that TOML should be used for the vast majority of what YAML's used for today. There are times a full language is needed, but I've seen so many YAML files that use none of the features YAML has with all of the footguns.
The thinking that would lead one to the conclusion of "yeah, fine, pick whatever characters you want for the string contents" is a "you are I are solving different problems"
Yaml is a sad Icarus parable. The syntax is great but the type inference is too much. I don't see why we have to throw the baby out with the bathwater and settle for toml, though.
Here's how yaml's type inference should work:
- All object keys are strings (with or without quotes)
- Value atoms are parsed the exact same way as in JSON5
I'm kinda shocked this isn't a thing. StrictYAML is cool but a bit too cumbersome IMO.
I wrote a really long blog post about this once without the clock metaphor.
This is far superior in illustrating the slippery slope.
Aside from that slide too an inevitable dinner with Turing completeness, there's often the problem of sourcing information from multiple files overlaying it backtracking where it's sourced from.
Docker files are an example of this, as is the complete list of config values in spring framework (it's like 30 different sources).
In addition config starts getting into secured secrets, service invocations, database lookups, operating system commands, and who else knows what.
So not only is it really a touring complete problem, it veers into hellscape that is system integration.
I'm a big fan of YAML after coming from JSON and, later, ProtoBuf's many definition formats while working at Google---but it's true that there are a lot of oddities in YAML's magical parsing. I'm grateful for the many ways it's possible to quickly an naturally define simple hierarchies of data (for example, in a docker-compose file).
This website does the rare thing of, after complaining, providing a long list of alternatives. It's really nice.
YAML's idea of human readability misses the mark. Especially anchors. They're the worst tools for abstraction.
JSON with functions as the high level format and JSON as the low level format is the way to go. Examples include Nix and Jsonnet. They're much nicer to deal with and less error prone.
Amusingly, the Stack Overflow answer you linked in your contribution is the second result in a Google search for "YAML multiline string" or the like, after yaml-multiline.info; the two combined appear to the canonical resource on the web.
Yawn. I'll keep using XML. While many waste their youth pointlessly reinventing XSDs in YAML/JSON/TOML/JSON5/HJSON, I'll still be here. Living. Content.
https://en.wikipedia.org/wiki/Property_list
If the price to pay is that there is some risk some dummy might start parsing the comments as code, so be it. This is not a really a problem in "regular" programming languages, I don't see why it would be in a configuration language.
But, then, I have to behave like a typical computer nerd and say..
Well ackchuallyyyyyy:
Browsers do stupid: <!--[if IE 8]>Linux does stupid: #!/bin/bash
C/C++ (preprocessor marcos) do stupid: #ifdef
https://en.wikipedia.org/wiki/Conditional_comment
https://en.wikipedia.org/wiki/Comment_(computer_programming)
It’s not a “magic comment” because it doesn’t depend on the runtime. It specifies an interpreter to use, regardless of the language of the file.
Eg you can use #!/usr/bin/python for a Python script. I don’t find it worse than the existing alternative of making the file name magic and finding and interpreter based on that.
It's a comment ignored by the interpreter (bash, python, whatever).
The kernel just says "Hey! You can't execute a text file, you weirdo! I'll just read the very first line of the text file and if it happens to be a comment that points to another executable, I'll run that and pass it this file."
https://go.dev/wiki/Comments#directives :-D
Plus non standard stuff is not a valid argument. As there are many tools which support non standard behaviour, because useful features like comment are considered non standard
1: https://github.com/ansible/ansible/blob/v2.18.4/lib/ansible/...
2: https://docs.ansible.com/ansible-core/2.18/dev_guide/develop... and https://github.com/ansible/ansible/blob/v2.18.4/test/integra...
I understand and appreciate the "why" of the format, but this also could have been a non-editable "editor-like" presentation and achieved the same result.
> # ps. By design, this website is as usable as YAML.
It's intentionally bad.
> The good news (I realised) was that you can select all the text of the site, and then delete it. Problem solved.
I guess it's like anything: for the right task, the right tool works well. But invariably, a tool will eventually be pushed into use for the wrong task.
or "I am doing ci job frontend, for each job I need to get a list of inputs it takes and their description, but without doing full code checkout" - good luck doing this if your jobs are in python/nodejs.
(to be fair, there are programming languages that are also severely limited and can be evaluated mostly safely, like Starlark, but I don't think they'd match your definition)
https://github.com/toml-lang/toml/blob/1.0.0/toml.md#user-co...
Here's how yaml's type inference should work:
- All object keys are strings (with or without quotes)
- Value atoms are parsed the exact same way as in JSON5
I'm kinda shocked this isn't a thing. StrictYAML is cool but a bit too cumbersome IMO.
This is far superior in illustrating the slippery slope.
Aside from that slide too an inevitable dinner with Turing completeness, there's often the problem of sourcing information from multiple files overlaying it backtracking where it's sourced from.
Docker files are an example of this, as is the complete list of config values in spring framework (it's like 30 different sources).
In addition config starts getting into secured secrets, service invocations, database lookups, operating system commands, and who else knows what.
So not only is it really a touring complete problem, it veers into hellscape that is system integration.
This website does the rare thing of, after complaining, providing a long list of alternatives. It's really nice.
JSON with functions as the high level format and JSON as the low level format is the way to go. Examples include Nix and Jsonnet. They're much nicer to deal with and less error prone.
Yay, octal numbers! But don't panic, lots of supposed C programmers fall for exactly the same trick when prefixing numbers with `0`.
Amusingly, the Stack Overflow answer you linked in your contribution is the second result in a Google search for "YAML multiline string" or the like, after yaml-multiline.info; the two combined appear to the canonical resource on the web.
Also, due to it failing to work as advertised, I just use `cfn-lint --info -e` to grab the transformed template and use that for realz.
#Operator: - Operand 1 - Operand 2
(context: I've never had to write 1000-line yaml files for kubernetes)