Fork me on GitHub
#babashka
<
2020-12-11
>
borkdude20:12:28

I'm currently thinking more about invoking clojure from babashka. This will satisfy the use case when your deps.edn map needs some dynamism, e.g. merging multiple maps together from multiple places, which currently isn't supported with the official clojure. The main question I'm asking right now is: should invoking (babashka.deps/clojure ...) return something or should that function just hand over control to the java process and exit accordingly to its return code. https://github.com/borkdude/babashka/issues/678

borkdude20:12:57

Maybe it's useful to return something and not exit in the case of -Spath, -Stree etc.

borkdude20:12:34

So maybe returning a babashka.process kind of thing and having its API available on the return value could work.

nate21:12:48

(babashka.deps/clojure ...) could hand back the babashka.process handle, so you can call check on it or do something else according to your use case...

nate22:12:50

makes the most sense for library behavior

borkdude22:12:55

The iffy part is that clojure sometimes does create a process (e.g. a REPL, or executing a file) but for some parts it doesn't, e.g. when invoking -Sdescribe or -Spath. So maybe it should only return a process when invoking main or exec.

nate23:12:05

it always starts a process (either bash+java or just bash), so it feels like its ok to always return a babashka.process process

borkdude23:12:49

that's not how it works in babashka because it's going to use borkdude/deps.clj. the bash is just in-process code.

borkdude23:12:09

i.e. no need to install the official clojure CLI, etc.

borkdude23:12:15

cross-platform solution

nate23:12:37

oh, gotcha

nate23:12:26

feels like there should be multiple functions in the namespace then, one for each major mode in the bash cli: 1. run a main 2. execute a function 3. ...

borkdude23:12:54

basically rewriting the CLI in fns... hmm. I'll contemplate that while sleeping. Thanks.

nate23:12:36

👍 rest well