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.
neuroticnews25 3 days ago [-]
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?
eduardoagarcia 2 days ago [-]
I'll see if I can come up with a better one soon
parentheses 3 days ago [-]
I feel that raw code is simpler to work with, more flexible and more ubiquitous (at least for bash).
eduardoagarcia 3 days ago [-]
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.
yjftsjthsd-h 3 days ago [-]
Could you provide those nice features like colors and interactive prompts as a library of shell functions that do work in bash?
Toutouxc 3 days ago [-]
META: Why are this guy's posts insta-dead? Is this because he registered and started "spamming" immediately (responding in this discussion)?
defrost 3 days ago [-]
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.
eduardoagarcia 3 days ago [-]
I appreciate it! I saw that was happening so I stopped replying. Long time listener, first time caller
bradhe 3 days ago [-]
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.
ajb 3 days ago [-]
>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
bradhe 2 days ago [-]
Yeah exactly, Python if you need all those features for safety. If portability is more important to you, maybe it’s OK to put up with the weird quirks of bash.
pwdisswordfishz 3 days ago [-]
Especially when this thing doesn't even seem to give any tractability benefits.
mattbillenstein 3 days ago [-]
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).
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.
eduardoagarcia 3 days ago [-]
I really like python as well (definitely one of my weapons of choice for one-off scripts)
linkdd 3 days ago [-]
> Shef is a powerful CLI tool for cooking up shell recipes.
I only see a YAML DSL. Where is my "shell"?
DrRobinson 3 days ago [-]
See `command:`
stagefright89 3 days ago [-]
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.
29athrowaway 3 days ago [-]
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.
rounce 3 days ago [-]
> 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.
fragmede 3 days ago [-]
the real fun happens when you're doing templates inside of templates and you have to figure out how to escape quote characters correctly
eduardoagarcia 3 days ago [-]
Valid! Also, is it weird I don't mind yaml? :P
belthesar 3 days ago [-]
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!
xigoi 2 days ago [-]
I like it as a configuration/data language, but not as a a pseudo-programming language.
pas 3 days ago [-]
+1 for CDK-like strongly-typed stuff :)
but that's simply in a different region of the solution space compared to Go + YAML
falcor84 3 days ago [-]
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.
okibry 3 days ago [-]
Can I reuse shef recipe in other shef recipe ?
eduardoagarcia 3 days ago [-]
Yeah, you can call anything within it. It might also be interesting to have common components that one can pull from.
mdaniel 3 days ago [-]
Yet another 'mustaches in yaml' that stepped on the same landmine ansible did
transform: "{{ filter .input 'Hello' }}"
3 days ago [-]
tiagod 3 days ago [-]
Cool project!
Would be nice to have one of those asciinema recordings to get a feel of how it works from the README :)
eduardoagarcia 3 days ago [-]
oh interesting idea, I'll definitely check it out and see what I can add, thanks!
eduardoagarcia 3 days ago [-]
added :) great suggestion!
layer8 3 days ago [-]
Kudos for the name, if nothing else.
akdor1154 3 days ago [-]
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'.
zenethian 3 days ago [-]
This seems mildly interesting but I'm not installing a bunch of Golang tools just to try it.
eduardoagarcia 3 days ago [-]
I very much agree! I figured if it had enough interest, we could work toward brew and other, better installation methods.
rounce 3 days ago [-]
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.
brontitall 3 days ago [-]
I’ve found goreleaser very helpful in the past. I notice it now claims support for non-go languages now
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.
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.
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/
Would be nice to have one of those asciinema recordings to get a feel of how it works from the README :)
But when your shell scripts get too complex, the answer is not 'wrap them in a Turing-complete yaml+jinja DSL'.
https://goreleaser.com/