bb gets installed by default to /usr/local/bin/bb if using the install script. simply removing that one file and doing a brew install should do it

bb is a single binary distribution

brew is better, specially on MacOS as you can manage updates in a cleaner more global way.

Will do. That’ll keep things more up to date too as brew tends to keep me more on the ball.

the install script is primarily targeted towards linux/unix users and things like CI or servers etc

It was worth it just to see how tiny the whole thing is… I was expecting a long download, out of habit, and it took about as long as running ls.

well the binary size is one of the most crucial aspects we try to control in bb. quite the factor when developing bb. pretty much you can see why 😄

we have #CSDUA8S6B for dev builds, which also shows you how much the binary size is of every master commit 🙂

Forgive my ineptness… where do I see the size in those channel listings? Just curious how to interpret them. Is it the last number?

no worries! its that number you see here, in bytes

yeah the one after the commit hash

I wasn't sure whether I felt 85MB was large or small. We're considering vendoring it into our repo at work but it will be the single largest file in git if we do. We already vendor in the entire Clojure CLI (the tools JAR is the only large file at 20MB) and an executable that powers our one remaining legacy app (46MB).

The zipped binary is around 25 mb. It’s still a bit smaller than Clojure-LSP

I wouldn’t put bb binaries into git personally. GitHub releases is where you can re-download it if you have to

Then you need wrapper scripts that download the specified version which complicates dev/test/CI setup and deployment.

So it's a tradeoff we've made on the above-mentioned binaries/JAR files.

Knowing that /var/www/worldsingles/build/bin/whatever is always accessible and the correct version, without needing all tiers to be able to download new stuff on-demand is a big pro.

That wrapper script we already have and supports a —version and —dir option

Oh, what is that?

Ah, you mean the install script could be under version control and you'd just run that first every time?

That's sort of OK for CI but it sucks for anything else that you might want to build off it.

Goal: run /path/to/some/script.clj that contains a shebang to use bb -- is there a command to substitute there for bb and have it auto-install/-update the bb executable and then run script.clj using that version of bb? That's the concrete case I'm talking about.

If it helps, bb.edn also supports :min-bb-version.

It doesn't really since a lot of scripts aren't going to have that file around.

If there was a bb.sh that auto-installed bb if it wasn't already present (or the right version) and then delegated to it, so you could have shebangs pointing at bb.sh and have everything "just work", that would be reasonable.

That's essentially what Leiningen does with its self-install (and several other tools I've used over the years).

We don’t have that but I guess it would be handy to have in your setup and the installer script could be called from there

On-demand, yes, so it would auto-install whatever version the script specified, if it wasn't already installed, and then just run as if it were the actual binary itself. Yeah, that would be nice. But having an 85MB binary in git isn't horrible 🙂

If i remember it was Bitbucket CI right? Is it self hosted? Maybe bb can be built into the runner base image or something?

BitBucket, yes, and we use clojure:temurin-18-tools-deps-1.11.1.1113 right now, but since we vendor the CLI ourselves, we could use a base Temurin image or indeed a Babashka image that also had a specified version of the JDK if such thing existed 🙂

But that would still mean that other developers would have to install it themselves -- although we could vendor the installer into our repo and just run it in CI which wouldn't be a big deal really (and developers could run it whenever we vendor in a new version).

Overall tho', having reviewed all our current shell scripts, there's not as much scope for converting things to bb as I'd initially hoped so this is all going to the backburner until we have more of an actual need (and since we run our build.clj as a REPL for a lot of stuff, the startup time isn't really an issue, although we do run a lot of tasks in subprocesses right now, since most of those fire up clojure or java processes anyway -- but those likely couldn't run as bb scripts).

Makes sense!

One more idea, since you're checking the bb binary into git. If you don't care about 250ms extra startup time, you may want to compress bb with upx: https://upx.github.io/ Which makes it the size of the original zip again and it will uncompress when you execute bb (which does take some CPU, but maybe not so much). I'm not using this myself because I prefer faster startup and don't check "large" binaries into git, but for your workflow this may be relevant.

Interesting, thanks. At this point -- with no real "need" for bb -- we're not putting it in the repo, but will bear that in mind for the future.

@U5H74UNSF bb -x supports this

but clj -M:,,, does not?

aha... yeah, I think that can be fixed

issue welcome!

great!

another question if I may: is there a way to figure out how I was called (`-X` vs -M?)

I want to support printing https://github.com/babashka/cli#help when called via -M

https://github.com/babashka/cli/issues/48

@U5H74UNSF You can print help regardless of -X / -M?

e.g. clojure -X :help true could also print help

but I'd like to print it differently?

-X would need a different help then -M?

I'll check in a minute, first trying to solve your first issue

I fixed the first issue but something went wrong on CI, just a minute

@U5H74UNSF Second issue: v0.5.40 • Add :org.babashka/cli {:exec true} to arg map's metadata when invoking functions with babashka.cli.exec.

This is how you can check it now

@U04V15CAJ thank you! 🙏🙏🙏

v0.5.40 isn't on maven yet: org.babashka:cli:jar:0.4.40 my bad!

@U04V15CAJ in action here https://github.com/nextjournal/clerk/commit/8be087166ef4308c6bfb4adafb5a0c68cd2200a0

nice :)