5 ms·
YAML is a nightmare fuel spec. In its quest to make markup "human readable", it has created countless footguns. I honestly prefer XML at this point.
by procone 2mo ago
YAML is a nightmare fuel spec.
In its quest to make markup "human readable", it has created countless footguns.
I honestly prefer XML at this point.
- fmbb 2mo agoIt’s find for actions and workflows as long as you do no interpolation and logic. Better move as much of that as possible into your own scripts. And your scripts can be portable between forges, and even run locally!
- NewJazz 2mo agoAssigning an env var to an empty variable (env: { myvar: ${{unsetfoo}} }) should trigger an error, not silently pass an empty string.
- RHSeeger 2mo agoThe YAML spec/parse _itself_ does interpolation and logic - incorrectly in some cases. YAML is pretty much never the right solution.
- formerly_proven 2mo ago> It’s find for actions and workflows as long as you do no interpolation and logic. How do you specify actions and workflows without interpolation and logic kind sir?
- NewJazz 2mo agoRun the same script for all of the workflow triggers and pass relevant vars into the script as environment variables.
- anonymars 2mo agoIn a similar vein, JSON's lack of comments makes me marvel at how consistently JavaScript seems to choose the worse option. I'm oh so glad it found its way into config files
- deleted 2mo ago[deleted]
- an0malous 2mo agoSeems more like the opposite vein, JSON's lack of comments or other affordances has kept it safe from footguns
- madeofpalk 2mo agoOf all the problems with YAML, how is comments a footgun?
- an0malous 2mo ago> or other affordances
- anonymars 2mo agoWell, while we're on the topic: "On the virtues of the trailing comma" https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=109379 https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=10...
- frollogaston 2mo agoThe idea is it makes people think they can use YAML for sketchy stuff as long as they comment on it.
- snackbroken 2mo ago[dead]
- xgulfie 2mo ago
- cgannett 2mo agoAnd thus procone spoketh the truth.
- codeduck 2mo agoIn accordance with the prophecy.
- hbn 2mo agoI never figured out how the hell to write YAML and I definitely won't now that I trust the AI to do a better job than me. It's so unintuitive. Every time I've tried in the past, something as simple as making a value a list had some nonsense expectations. I can't wrap my head around how that spec got any traction and wasn't laughed off the face of the earth the first time it was looked at by someone who didn't create it.
- frollogaston 2mo agoI don't get it either. There was a point where I had to write YAML, but it wasn't intuitive to begin with, and months in I was still accidentally setting the wrong number of indents or some nonsense.
- doix 2mo agoYeah, the YAMLification of everything kinda killed my ability to understand "everything". Previously, if you knew the Linux userland well, I felt like you could figure anything out with enough digging. Take CI for example, it was Jenkins and it ran a csh/bash/zsh whatever script and captured the output. Nice and simple (even if the scripts sometimes got insane). GitHub actions is nothing like that. Weird home grown extensions to YAML with their own idiosyncrasies and dynamically pulling in plugins from god knows where. You can't just take a workflow and execute it locally like you could with a bash script.
- muvlon 2mo agoAnd worse: GitHub Actions not a full-fledged programming environment by itself either, so you're inevitably going to have to deal with nontrivial shell scripts on top of all the YAML mess.
- fragmede 2mo agoYeah. It makes sense when you're standing right next to it, but you take a step back and go "that doesn't look right". GitHub actions is the faster horse instead of a car.
- jeroenhd 2mo agoThe things done in yaml today would've been obscure bash oneliners had YAML not existed. Jenkins still exists and it's no less complicated than Github Actions. The complexity gets hidden in obscure script files, obscure tabbed UI, and remote services for doing things Jenkins itself can't do. Defaulting to system tooling makes it almost impossible to predict what a job will do unless you know exactly how paths and tooling are set up (and what versions they're running). None of my personal experiences with Jenkins had scripts that ran locally, they all relied on pre-installed software on the server because that was the thing people would do before the great YAMLification. You could copy-paste the Jenkins job, but unless you have Jabberwocky v2018.3 installed in /home/JabberWock/RELEASE, the script will fail. The entire software development flow has been made incredibly complex by hooking up automations into every nook and cranny. All of these complications need to be enabled manually, though. If your flow is complicated, you can cut it down to manageable size by doing a few more processes manually. Luckily, all of the simplication and reproduction steps for Github also apply to Jenkins. Github YAML files are just scripts with different syntax, after all. Just like you can run bash locally, you can run act and reproduce whatever Github trigger you need. From there, you can simplify pipelines, stop curl2bashing "plugins", and so on.
- voakbasda 2mo agoWhen I see YAML in a product tech stack, I know that the developers have probably made other similarly poor life decisions and try to steer clear of the entire iceberg.
- frollogaston 2mo agoTextproto is such much better than YAML for everything that YAML is used for. Sure, JSON has plenty of uses, but YAML is specifically used for configs that it's terrible at.