Looks like theres some relevant discussion https://github.com/babashka/babashka/discussions/869 and https://clojureverse.org/t/help-utilizing-babashka-tasks-globally/8026/2 . Still reading to see what I'm missing.

Crikey. Thanks,

cat $(which bbthingy)
#!/usr/bin/env bash

set -euo pipefail

bb --config "${UTIL_REPO_ROOT}/bb.edn" --deps-root "${UTIL_REPO_ROOT}" $@

I was just messing with something similar - I made a script called 'bbt' and used --config $(dirname $0)/tasks.edn with a tasks.edn in that same dir, and then running that script from somewhere else will use the tasks from tasks.edn but will be contextualized to $PWD (because I'm too lazy to set another env var) 🙂

I use direnv to help with env vars.

with that said, I feel like 'global tasks' can often be a good use case for a script, and then potentially install the script with bbin if desired

At the root of the project where I'm working (not where the bb tasks and source are)

% cat .envrc
dotenv
PATH_add "${PWD}/bin"
% cat .env
UTIL_REPO_ROOT=${HOME}/repos/bb-util

(using the term 'install' in the loosest possible sense there)

I build up a lot of cljc that I want to be able leverage in other projects without including them as dependencies or installing them in a bunch of different places. bbin might be useful: I'll take a look. It'd be one more thing to learn, though, for me and the team. we already have bash and direnv

Bb will already respect a script-adjacent bb.edn

~/pkg-utils/bb.edn # contains pkg task
~/pkg-utils/pkg 

#!/usr/bin/env bb
(babashka.tasks/run 'pkg)

and when you want to make it more dynamic:

~/pkg-utils/mypkg

#!/usr/bin/env bb
(def task (symbol (first *command-line-args*)))
(binding [*command-line-args* (next *command-line-args*)]
(babashka.tasks/run task))

then:

~/some-project/my-pkg pkg --args 

Some people have suggested that bb.edn itself should be made executable, that would make this a bit easier. pkg:

#!/usr/bin/env bb
{:tasks ...}

(this currently is not supported)

Thanks for the feedback. At first blush, I think making bb.edn executable is a move away from simplicity and being data driven. Not likely a feature I would want to take advantage of, and probably find frustrating to debug in practice.

The script-adjacent bb.edn is interesting. I'll play with that in the future.

Thanks!

Bb.edn would remain data, it being executable would just mean you wouldn’t have to provide a script wrapper

Github actions doesn’t support aarch64 but you can release bb programs as self contained binaries for every platform using GitHub actions

Afk right now, search channel for details

thanks!

I've been trying out BuildJet as an alternative runner for GHA - it supports ARM https://buildjet.com/for-github-actions

For bb I'm using cirrusCI for aarch64 mac and circleci for aarch64 linux and all other stuff, except windows which runs on appveyor

about self-contained bins: https://github.com/babashka/babashka/wiki/Self-contained-executable#uberjar

Right so you just need to cat the uberjar out on each platform. I can probably get by at this point without mac/arm. So do these binaries require a JRE to be present?

No they don’t and you don’t need to do this ON each platform but FOR each platform. You can build for Windows on Linux as long as you download the Windows binary

ohhhhh

slick

Thanks so much for the help. BTW it’s for this https://github.com/smith/esql-tools/tree/main/esqshell, which is a fun side project I’m doing to learn but could become part of a real product some day. Hopefully they don’t rewrite it in go 😄

Nice

Do you happen to know what permissions are needed for that release_artifact script to work? I’m getting a 403 https://github.com/smith/esql-tools/actions/runs/7202008837/job/19619297303

(nm I think I can set it in the workflow permissions)

WOO HOO! Good enough, I’m going on holiday for the rest of the year. Thanks again ⛄ https://github.com/smith/esql-tools/releases

I don’t see any release there

of course

Maybe I'll take a stab at that ☺️

sure

About to go on paternity leave. If the kid behaves, I might have some time on my hands 😅

most of core.async is available, and for really quick stuff maybe just pmap (but that uses futures, so you might want a shutdown-agents call at the end)

$ bb -e '(pmap #(babashka.process/shell "echo" %) (range 10)) (shutdown-agents)'
3
2
6
...

Thank you Bob for the recommendation. I'll give pmap a try first.