Fork me on GitHub
#babashka
<
2022-10-09
>
seancorfield23:10:09

Finally decided to start using bb for shell stuff (I know -- slow on the uptake here!) and switched next.jdbc's run-tests.sh to https://github.com/seancorfield/next-jdbc/blob/develop/run-tests.clj

🚀 6
seancorfield00:10:37

Hints and tips on improving my bb usage/idioms welcome since I'm new to it! 🙂

Bob B02:10:34

Given the context, a feature that you might like is "babashka tasks" (<https://book.babashka.org/#tasks>). In this case, a lot of the 'post-processing' of the clojure invocation can be handled by tasks 'clojure' function... bb.edn lets you define tasks:

; bb.edn excerpt with a mocked-up task, could be replaced with -X... call
{:tasks {demo-fail
         {:doc  "print something and then fail with exit code 23"
          :task (let [env {"FOO" (first *command-line-args*)}] 
                  (clojure {:extra-env env} 
                           "-M -e '(println (System/getenv \"FOO\"))
                                   (System/exit 23)'"))}}}
and then from the directory where bb.edn lives:
$ bb tasks
The following tasks are available:

demo-fail print something and then fail with exit code 23
$ bb demo-fail maria
maria
Error while executing task: demo-fail
$ echo $?
23
the 'clojure' function uses deps.clj to invoke the JVM (which uses babashka.process), so the options are more or less the same, and it handles the exit code processing (if you like that kind of thing)

seancorfield02:10:09

@U013JFLRFS8 Yeah, unlikely I'll use that because my scripting outside of work is pretty simple stuff -- and at work we use build.clj and have the Clojure CLI vendored into our repo so that every tier only has to have a JDK and then they all use the same version of the CLI without us needing to so any ops at all to install stuff.

seancorfield02:10:51

(and my OSS projects also tend that way for anything I might run in CI -- what I showed above was just a convenience script I run locally)

lispyclouds02:10:23

I use tasks more as a way to abstract myself from the CI intricacies too. More often than not i have to hop CIs and have a mix of CIs, hence its nice there but maybe it could me a "me problem" 😅

lispyclouds02:10:09

i do have a fairly complex flow with parallel things, error recovery, cleanup etc in tasks. feels nicer than the YAML for me

seancorfield02:10:09

@U7ERLH6JX How do you setup bb for CI? (and which CI are you using)

lispyclouds02:10:06

mostly circle. its pretty much uses the linux install script: https://github.com/bob-cd/bob/blob/main/.circleci/config.yml#L22

seancorfield02:10:55

Ah, OK, so it's installing bb every time for Circle (or, say, BitBucket).

lispyclouds02:10:41

if you have a container based executor, you can use the bb docker image we publish too

seancorfield02:10:17

Good to know re: GH Actions. Thanks.

seancorfield02:10:35

Also good to know re: Docker image -- does that also have a JDK etc? Or is it barebones with just bb?

lispyclouds02:10:00

we even implement bb's ci logic in bb itself , just saying if you wanna go down that rabbit hole : https://github.com/babashka/babashka/blob/master/.circleci/script/short_ci.clj 😛

lispyclouds02:10:54

> Docker image -- does that also have a JDK etc? Or is it barebones with just bb Its just bb and the only dependency it optionally needs: curl

lispyclouds02:10:02

happy to answer any of bb and bb based ci/orchestration/build questions! most of it i was a part of building 😄

seancorfield02:10:46

OK, so without Java, that means you can't run clojure in that Docker image:

seanc@Sean-win-11-laptop:~/clojure$ docker run --rm babashka/babashka bb clojure --version
Exception in thread "main" java.lang.Exception: Couldn't find 'java'. Please set JAVA_HOME.
        at borkdude.deps$_main.invokeStatic(deps.clj:439)
        at borkdude.deps$_main.doInvoke(deps.clj:428)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at clojure.core$apply.invokeStatic(core.clj:667)
        at babashka.deps$clojure.invokeStatic(deps.clj:43)
        at babashka.deps$clojure.invoke(deps.clj:7)
        at babashka.deps$clojure.invokeStatic(deps.clj:31)
        at babashka.main$exec.invokeStatic(main.clj:954)
I wasn't sure how bb actually ran its clojure command 🙂

seancorfield02:10:08

So if you want to use bb with Clojure stuff in a Docker image, you need to start with the clojure images and add bb at startup...

lispyclouds02:10:46

yeah that uses https://github.com/borkdude/deps.clj which would use the JVM clojure to fetch deps and build classpath. the idiom we generally do is in docker we do a multistage build: • get the deps in a java+bb image • use the next stage with a minimal bb image

lispyclouds02:10:15

once the stuff is there on the classpath bb wont need the JVM anymore

seancorfield02:10:02

Ah, so you generate the classpath from the JDK image and store it (in a file?) and then use that in the bb image in the next stage?

seancorfield02:10:58

(but you're still limited to whatever bb can actually run with, so you can't run arbitrary Clojure code)

lispyclouds02:10:04

you could copy over the ~/.m2 in the next stage. when loading the deps its the same maven like logic

seancorfield02:10:57

Right... yeah, I'm used to BitBucket which caches ~/.m2 but only refreshes its caches once every two weeks unless you do it manually!

lispyclouds02:10:18

essentially the way we build bb, after the compilation, we dont have the JVM anymore, specially the JIT infra. so anything that produces bytecode and/or needs compilation to bytecode wont run in bb.

lispyclouds02:10:27

it is an interpreter after all.

seancorfield02:10:19

Yeah, it's going to take me a bit to wrap my head around what I would actually use bb for... which is why it's taken me so long to actually install it...

seancorfield02:10:30

At work, we have some shell scripts that may or may not make sense to switch to bb but the tradeoff is that we'd need bb on every server -- or vendored into our repo, like we do for the Clojure CLI -- and once we have the latter, it's somewhat hard to justify the former, just for "shell" scripts, esp. when startup time isn't really an issue for pretty much anything we run...

seancorfield02:10:06

(and we already run a bunch of stuff in dev/test/CI via build.clj and the full tools.build/`tools.deps.alpha` stack)

lispyclouds02:10:06

in general, if youre already using mostly jvm clojure and arent too sad about the startup time, keep using that. if theres an explosion of "glue" shell stuff and its too hard to understand/you wish you had clojure there, you know where to look 😄

seancorfield02:10:42

My intention here is to try to "train" myself to turn to bb first and bash second, where I wouldn't instantly just stick something into my build.clj file 🙂

👍 1
lispyclouds02:10:50

yeah the "batteries included" nature of bb could be another motivation for you too: https://book.babashka.org/#libraries

seancorfield02:10:02

I see clojure.tools.cli there (which I maintain). I just cut a new minor release of that -- what version does bb use and how could I figure that out? How quickly does bb pick up new versions of those libraries?

lispyclouds02:10:29

picking up libs are fairly quick. can attribute to borkdude's inhuman efficiency 🙏:skin-tone-3:

seancorfield02:10:45

Cool. So it's just a matter of getting all those updated before the next bb build/release? Oh... :rolling_on_the_floor_laughing:

lispyclouds02:10:37

yeah bb is produced like any other clojure project. has the jar and everything. just that things change after GraalVM eats that jar 😛

lispyclouds02:10:45

we could do that i guess! its mostly PR driven now i think

borkdude06:10:19

@U04V70XH6 Built-in libs like tools.cli can be overriden, if you add the lib to bb's classpath and use (:require [...] :reload)

borkdude06:10:55

$ bb -Sdeps '{:deps {org.clojure/tools.cli {:mvn/version "1.0.214"}}}' -e "(require '[clojure.tools.cli :as cli] :reload) (cli/summarize (cli/compile-option-specs [[\"-b\" \"--boolean\" \"Bla\" :default true]]))"
"  -b, --boolean  true  Bla"

seancorfield06:10:41

Ah, cool. Good to know @U04V15CAJ Thanks!

borkdude06:10:06

We also have this page with supported projects: https://babashka.org/toolbox/

borkdude07:10:49

With p/shell it is fine, but should not be necessary to do this: https://github.com/seancorfield/next-jdbc/blob/5557a0e16c0eff1effab79c94a096e8a7992f8e0/run-tests.clj#L13-L14 Since shell (unlike the other functions in process) already automatically checks its exit code and throws if it's non-zero

borkdude07:10:39

Awesome first script :)

borkdude09:10:44

Since you are using VScode, this might be interesting too: https://marketplace.visualstudio.com/items?itemName=fbeyer.babashka-tasks

❤️ 1
lread11:10:42

Welcome to the wonderful world of cross-platform scripting in Clojure @U04V70XH6! I knew you'd come around eventually!

lread11:10:17

Did anybody mention the https://github.com/DeLaGuardo/setup-clojure? It can also setup bb.

lispyclouds11:10:45

might i also add cross-platform and truly multithreaded scripting 😄

🚀 2
lispyclouds11:10:12

> Did anybody mention the setup-clojure GitHub Action yet? I mentioned the setup bb one, but yes this is more general and nicer!

lread11:10:32

My personal pref is to use bb tasks to abstract the tasks for a project. It's nice to go to one of my projects and type bb tasks . And then be able to quickly run a task with very few keystrokes. But I did start with bb scripts only first.

borkdude15:10:53

You can start out with just script/foo.clj and then hook up the script in bb.edn using load-file later

lread15:10:58

Yeah my scripts were easy to hook up to tasks.

seancorfield15:10:42

@U04V15CAJ Ah, yes, I had been trying various combinations of things, including ProcessBuilder directly, before I ended up there so it's sort of leftover from earlier code. I started with clojure.java.shell, then went to p/process, then ProcessBuilder, then p/shell because it wasn't entirely clear from the book which would better for my use case (specifically: adding environment variables). Also, it took me a while to realize that :env replaces all the environment variables, which I'm pretty sure c.j.s/sh does not?

borkdude16:10:06

It does. Compare:

user=> (:out (sh "bash" "-c" "echo $PATH"))
to:
user=> (:out (sh "bash" "-c" "echo $PATH" :env {"FOO" "bar"}))

seancorfield20:10:56

Ah, interesting. I've never tripped over that before (but tripped over it straight away running tests) so I guess I've just been lucky in the past. Thank you!

👍 1