[HN Gopher] Shef
       ___________________________________________________________________
        
       Shef
        
       Author : eduardoagarcia
       Score  : 128 points
       Date   : 2025-03-11 00:16 UTC (22 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | tiagod wrote:
       | Cool project!
       | 
       | Would be nice to have one of those asciinema recordings to get a
       | feel of how it works from the README :)
        
         | eduardoagarcia wrote:
         | oh interesting idea, I'll definitely check it out and see what
         | I can add, thanks!
        
         | eduardoagarcia wrote:
         | added :) great suggestion!
        
       | okibry wrote:
       | Can I reuse shef recipe in other shef recipe ?
        
         | eduardoagarcia wrote:
         | Yeah, you can call anything within it. It might also be
         | interesting to have common components that one can pull from.
        
       | newsyco21 wrote:
       | ok
        
       | stagefright89 wrote:
       | i hate yaml as it is and it makes working with k8s hard. this imo
       | makes shell scripts worse
        
       | stagefright89 wrote:
       | 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 wrote:
         | 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 wrote:
           | > 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 wrote:
           | 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 wrote:
         | Valid! Also, is it weird I don't mind yaml? :P
        
           | belthesar wrote:
           | 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!
        
           | pas wrote:
           | +1 for CDK-like strongly-typed stuff :)
           | 
           | but that's simply in a different region of the solution space
           | compared to Go + YAML
        
           | xigoi wrote:
           | I like it as a configuration/data language, but not as a a
           | pseudo-programming language.
        
       | mdaniel wrote:
       | Yet another 'mustaches in yaml' that stepped on the same landmine
       | ansible did                 transform: "{{ filter .input 'Hello'
       | }}"
        
       | parentheses wrote:
       | I feel that raw code is simpler to work with, more flexible and
       | more ubiquitous (at least for bash).
        
         | eduardoagarcia wrote:
         | 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.
        
           | Toutouxc wrote:
           | META: Why are this guy's posts insta-dead? Is this because he
           | registered and started "spamming" immediately (responding in
           | this discussion)?
        
             | defrost wrote:
             | 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 wrote:
               | I appreciate it! I saw that was happening so I stopped
               | replying. Long time listener, first time caller
        
           | yjftsjthsd-h wrote:
           | Could you provide those nice features like colors and
           | interactive prompts as a library of shell functions that do
           | work in bash?
        
         | bradhe wrote:
         | 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 wrote:
           | >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
        
         | pwdisswordfishz wrote:
         | Especially when this thing doesn't even seem to give any
         | tractability benefits.
        
       | renewiltord wrote:
       | 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.
        
       | zenethian wrote:
       | This seems mildly interesting but I'm not installing a bunch of
       | Golang tools just to try it.
        
         | eduardoagarcia wrote:
         | I very much agree! I figured if it had enough interest, we
         | could work toward brew and other, better installation methods.
        
           | rounce wrote:
           | 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 wrote:
             | I've found goreleaser very helpful in the past. I notice it
             | now claims support for non-go languages now
             | 
             | https://goreleaser.com/
        
               | Y_Y wrote:
               | Gore Leaser
        
         | eduardoagarcia wrote:
         | I've updated it to include binary assets on the releases :)
        
       | mattbillenstein wrote:
       | 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.
        
         | eduardoagarcia wrote:
         | I really like python as well (definitely one of my weapons of
         | choice for one-off scripts)
        
         | khimaros wrote:
         | or a middle path solution like https://github.com/pyinfra-
         | dev/pyinfra
        
         | linsomniac wrote:
         | 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
        
       | linkdd wrote:
       | > Shef is a powerful CLI tool for cooking up shell recipes.
       | 
       | I only see a YAML DSL. Where is my "shell"?
        
         | DrRobinson wrote:
         | See `command:`
        
       | akdor1154 wrote:
       | 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'.
        
       | neuroticnews25 wrote:
       | 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 wrote:
         | I'll see if I can come up with a better one soon
        
       | layer8 wrote:
       | Kudos for the name, if nothing else.
        
       | falcor84 wrote:
       | 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/
        
       | diegof79 wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2025-03-11 23:01 UTC)