Fork me on GitHub

Let’s say you have multiple tasks which are mainly the same except for modification to a switch, or an env here and there, what strategy do others use to reduce to duplication?

 {dev-app   {:task (shell "clj -M:alias-a:alias-b")}
  dev-app:b {:task (shell {:extra-env "ENV"} "clj -M:alias-a:alias-b")}
  dev-app:c {:task (shell "iced repl --middleware=["stuff"] clj -A:alias-a:alias-b")}}}
I’m not actually bothered by the repetition, I just noticed I was doing this and thought to see if maybe others run into this. TIA!!


@tkjone you can use the same strategy as in normal programs: write a function :) you can put it in :init


figured that would be it 😉


Something that came up in a recent work project: it’d be really nice to have a shell option in babashka.process like there is for Python’s In this particular case I needed to source an env file before starting a java process. Instead, I ended up building the command as a string and sending it to a bash babashka.process via stdin, which was fine but a little clunky. I’d imagine a shell option would be useful in other circumstances as well


from my perspective, including the shell=True option like pythons Popen would make it platform dependent, have not simple conditional OS specific logic and also make the need to have a relevant shell present. afaik python defaults to /bin/sh but if your env has bash syntax for example it would crash it again. I would just use something like (babashka.process/sh "bash -c 'source ~/.env && java -jar app.jar'") this is quite explicit and unlike shell=True doesnt depend on something outside the program implicitly. Also the py docs mention:


You can put environment variables in the :extra-env option as the first argument to shell


So there is no need to fabricate your own bash env stuff


That requires me to parse the .env file into clojure data structures. Some of the values could be derived from other environment variables or arbitrary bash commands. Unfortunately, the only practical way to evaluate it is with source.


alright, yeah you can just invoke bash -c "foo" and be done with it then


Right, that’s more or less what I ended up doing, except I piped the actual command in via stdin to avoid messing around with quoting. Not saying it’s an unsurmountable problem, just one that’s probably common enough that it might be worth having built-in functionality for. If not, no worries, I’ve got my utility fn!