Uff, this brings back memories of Maven 1 and Apache Jelly.
Jelly was a scripting language using XML. It was an aberration, and Maven 2 removed it. This feels like Jelly, but in YAML instead of XML.
I don't intend to offend the author, but I don't see the use case for writing the recipes in YAML instead of using a shell function (or Python, which is multiplatform). The YAML metadata will work if you have a sort of low-code UI or want to show the steps in a UI (which is the main reason CI/CD platforms use it). I guess the author got used to the CI/CD YAML pipeline configuration files and wanted a similar experience.
However, it will quickly end up being a pseudo-programming language without the benefits of a better composition syntax.
As I was developing Shef, I kept asking myself if just knocking out a bash script was easier than making a recipe in yaml. In a lot of ways, absolutely. But I kept coming back to the embedded user prompts and a few of the other features that add some nice benefits on top of bash scripting. But all in all, you raise valid points.
I agree with this statement. The world is absolutely chock full of weird control flow constructs layered on top of YAML. When I opened this repo and saw it was YAML driven I just rolled my eyes.
With just a little bit of effort, shell scripting really isn’t that arcane.
>With just a little bit of effort, shell scripting really isn’t that arcane.
It isn't, but at least bash and posix shell don't really have scoping, structured variables, or reliable error handling (too many ways an error code can be invisibly dropped)
To get them, you need to use a
less used shell like hush or powershell. And one reason those haven't taken over, is that if you have to add a dependency you might as well use a full language anyway. But I agree that YAML isn't a good option for scripting either
Yeah, just prefer writing little cli tools in Python or something once the shell script gets too complex...
Sorta hate yaml drive config management and deployments sytems aka ansible, saltstack, etc; so ended up writing my own that's salt-like, but all python.
A couple years ago I did some experimenting with applying Ansible ideas on a smaller scale (like a shell script rather than operating on fleets of machines). I started off with using YAML and some alternate syntaxes, because I was coming from ansible.
But then I decided I really kind of despise "programming" in YAML (conditionals and loops in particular). So I adapted Ansible ideas to Python, in particular: idempotent commands and notifications (commands triggered later, when another set of commands make a change; like restarting apache after making a bunch of config changes).
yaml sucks to work with as it is. i work with k8s day in and out. this to me seems like a bad idea taking away the programmability with a tightened structure. For beginners who can't write shell scripts well, this may seem promising. Cool concept though. just not very practical imo.
> Not that hard to write something that outputs YAML.
The point of this is to lower the entry cost of producing interactive CLI apps. If I have to break out a more expressive language to use it I may as well just write my program in that language in the first place.
> The usefulness of YAML is having declarative files that are simple.
There are other config formats that provide this and don’t rely on sometimes ambiguous whitespace based structure (eg. TOML). While you can write JSON in a YAML file to avoid this, you’ve then nullified all of the supposed ‘benefits’ of YAML.
Not at all! I think there's a pretty natural flow for folks to have a love affair with YAML over the past decade or so of comp sci. You're seeing plenty of folks with "YAML DSL fatigue" because folks have seen this pattern many many times, and I imagine are a bit gunshy of "yet another YAML thing". That said, I have regular conversations with someone who would rather do everything he could in Ansible if he could, where I've become a fan of using CDKs since the power of an existing language's primitives combined with specialized knowledge distilled and packaged in an API I can call gives me superpowers. You're comfy in YAML and that's awesome. Keep making stuff that vibes with you!
I was going to mention a naming collision with the shell tool in the Chef configuration management suite, which used to also be called `shef` (going for the same pun as here), but looking at their docs now [0], it seems they removed that name in favor of just `chef-shell`, so no issue here.
I'm sure someone somewhere has some use for this but I would prefer the raw shell. It reminds me of https://taskfile.dev/getting-started/ which has checkpointing and so on but where I still end up using raw shell.
Readit News
Jelly was a scripting language using XML. It was an aberration, and Maven 2 removed it. This feels like Jelly, but in YAML instead of XML.
I don't intend to offend the author, but I don't see the use case for writing the recipes in YAML instead of using a shell function (or Python, which is multiplatform). The YAML metadata will work if you have a sort of low-code UI or want to show the steps in a UI (which is the main reason CI/CD platforms use it). I guess the author got used to the CI/CD YAML pipeline configuration files and wanted a similar experience.
However, it will quickly end up being a pseudo-programming language without the benefits of a better composition syntax.
With just a little bit of effort, shell scripting really isn’t that arcane.
It isn't, but at least bash and posix shell don't really have scoping, structured variables, or reliable error handling (too many ways an error code can be invisibly dropped)
To get them, you need to use a less used shell like hush or powershell. And one reason those haven't taken over, is that if you have to add a dependency you might as well use a full language anyway. But I agree that YAML isn't a good option for scripting either
Sorta hate yaml drive config management and deployments sytems aka ansible, saltstack, etc; so ended up writing my own that's salt-like, but all python.
But then I decided I really kind of despise "programming" in YAML (conditionals and loops in particular). So I adapted Ansible ideas to Python, in particular: idempotent commands and notifications (commands triggered later, when another set of commands make a change; like restarting apache after making a bunch of config changes).
https://github.com/linsomniac/uplaybook?tab=readme-ov-file
https://github.com/mattbillenstein/salty
Been using this on a couple startups for a couple years, but it lacks polish in terms of user-friendliness.
Interesting how we came to some of the same types of things - like you have .notify() - I return a result object with a "changed" flag, etc.
I only see a YAML DSL. Where is my "shell"?
The usefulness of YAML is having declarative files that are simple.
But once you start adding templating it sucks as much as anything else.
The point of this is to lower the entry cost of producing interactive CLI apps. If I have to break out a more expressive language to use it I may as well just write my program in that language in the first place.
> The usefulness of YAML is having declarative files that are simple.
There are other config formats that provide this and don’t rely on sometimes ambiguous whitespace based structure (eg. TOML). While you can write JSON in a YAML file to avoid this, you’ve then nullified all of the supposed ‘benefits’ of YAML.
but that's simply in a different region of the solution space compared to Go + YAML
[0] https://docs.chef.io/workstation/chef_shell/