Fork me on GitHub
#babashka
<
2021-08-14
>
athomasoriginal15:08:46

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?

{:tasks 
 {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!!

borkdude15:08:11

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

athomasoriginal15:08:44

figured that would be it 😉

Max22:08:02

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 https://docs.python.org/3.9/library/subprocess.html#subprocess.Popen. 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

lispyclouds06:08:51

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: https://docs.python.org/3.9/library/subprocess.html#security-considerations

borkdude07:08:18

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

borkdude07:08:23

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

Max15:08:12

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.

borkdude15:08:52

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

Max01:08:05

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!