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).
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.
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 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!
> 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.
It’s a Golang project, one of the big selling points of Go is the ability to easily produce static binaries which are easily distributed. It’s trivial to setup basic GitHub actions and build and publish a release containing binaries for all platforms.
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.
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.
I think the demo gif isn't very good, because it doesn't illustrate what this tool can be actually useful for. Or do I just lack imagination?
I'll see if I can come up with a better one soon
> Shef is a powerful CLI tool for cooking up shell recipes.
I only see a YAML DSL. Where is my "shell"?
See `command:`
I feel that raw code is simpler to work with, more flexible and more ubiquitous (at least for bash).
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.
Could you provide those nice features like colors and interactive prompts as a library of shell functions that do work in bash?
META: Why are this guy's posts insta-dead? Is this because he registered and started "spamming" immediately (responding in this discussion)?
Might be an algo thing, might be a trigger happy "enhanced" user that doesn't like green accounts.
FWiW the comments look fine to me and I've just [vouch]'d each and every one .. if some one else or two does the same they should come back.
I appreciate it! I saw that was happening so I stopped replying. Long time listener, first time caller
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
Especially when this thing doesn't even seem to give any tractability benefits.
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.
or a middle path solution like https://github.com/pyinfra-dev/pyinfra
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).
https://github.com/linsomniac/uplaybook?tab=readme-ov-file
I really like python as well (definitely one of my weapons of choice for one-off scripts)
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.
[0] https://docs.chef.io/workstation/chef_shell/
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.
Valid! Also, is it weird I don't mind yaml? :P
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 like it as a configuration/data language, but not as a a pseudo-programming language.
+1 for CDK-like strongly-typed stuff :)
but that's simply in a different region of the solution space compared to Go + YAML
Not that hard to write something that outputs YAML.
The usefulness of YAML is having declarative files that are simple.
But once you start adding templating it sucks as much as anything else.
> 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.
the real fun happens when you're doing templates inside of templates and you have to figure out how to escape quote characters correctly
Yet another 'mustaches in yaml' that stepped on the same landmine ansible did
Can I reuse shef recipe in other shef recipe ?
Yeah, you can call anything within it. It might also be interesting to have common components that one can pull from.
Kudos for the name, if nothing else.
Cool project!
Would be nice to have one of those asciinema recordings to get a feel of how it works from the README :)
oh interesting idea, I'll definitely check it out and see what I can add, thanks!
added :) great suggestion!
Holy hell, burn it with fire. No offence intended to the author, it's probably coded fine.
But when your shell scripts get too complex, the answer is not 'wrap them in a Turing-complete yaml+jinja DSL'.
This seems mildly interesting but I'm not installing a bunch of Golang tools just to try it.
I've updated it to include binary assets on the releases :)
I very much agree! I figured if it had enough interest, we could work toward brew and other, better installation methods.
It’s a Golang project, one of the big selling points of Go is the ability to easily produce static binaries which are easily distributed. It’s trivial to setup basic GitHub actions and build and publish a release containing binaries for all platforms.
I’ve found goreleaser very helpful in the past. I notice it now claims support for non-go languages now
https://goreleaser.com/
Gore Leaser
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.
i hate yaml as it is and it makes working with k8s hard. this imo makes shell scripts worse
[dead]
ok