Earlier quoted context omitted.
I want multiline strings and references
Have you considered XML?
Or heck, PLists. They have an XML representation that is fairly similar to what JSON can express.
That's a Lot of YAML
41–50 of 57 posts
Re: That's a Lot of YAML
#42Earlier quoted context omitted.
What's even better is just using an actual programming language. Not bash, not sed, not yaml. Just python or NodeJS.
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.
Re: That's a Lot of YAML
#43I can take credit for one of these, the 63 ways to wrap a string, on line 156.
That's what https://yaml-multiline.info is for! I know the author's on HN, I hope they chime in here :) 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.
Heh, not sure if you realise, but that website was inspired by my SO answer. (I'm credited at the bottom).
Re: That's a Lot of YAML
#44This 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.
This site is beautiful in it's own way.
Its. It's is a contraction of it+is
Re: That's a Lot of YAML
#45This 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.
I just read it here: https://raw.githubusercontent.com/ghuntley/noyaml/refs/heads...
Re: That's a Lot of YAML
#46I find the configuration complexity clock always valuable in framing conversations like this: https://mikehadlow.blogspot.com/2012/05/configuration-comple...
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.
Re: That's a Lot of YAML
#47Earlier quoted context omitted.
Have you considered XML?
Or heck, PLists. They have an XML representation that is fairly similar to what JSON can express. https://en.wikipedia.org/wiki/Property_list
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
Re: That's a Lot of YAML
#48Yaml 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,]
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)
...
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...
Re: That's a Lot of YAML
#49I 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"
https://github.com/toml-lang/toml/blob/1.0.0/toml.md#user-co...
Re: That's a Lot of YAML
#50Earlier quoted context omitted.
For a configuration language, comments are absolutely crucial. You want to be able to say "# This option is set because " 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 se…
I will start by saying, I completely agree with you! But, then, I have to behave like a typical computer nerd and say.. Well ackchuallyyyyyy: > "This is not a really a problem in "regular" programming languages" Browsers do stupid: 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)
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.