🧵

I have a good usecase for this, will investigate this afternoon and report back 🙂

i didnt try it but this confused me

cat ./bb uber.jar > my-binary

wait does it mean, one would first use uberjar and then concat it to the end of bb ?

Having invested in using the bb tasks approach, is there any way that that could be wrapped into an uberjar?

@U4C3ZU6KX tasks are project-specific, at least that is the intention

I do recall something with bb.edn in an uberjar being picked up so maybe it works

I'll try locally

Interesting - I see them as alternative entry points into my code. The :init acts as the first part of a main and the task then is as if the main calls a particular end point.

@U4C3ZU6KX I'd probably use babashka.cli subcommands for your use case: https://github.com/babashka/cli#subcommands

Neat. Thanks.

@U4C3ZU6KX I found a way to run bb tasks in a self-contained binary. Use this as your main entry point:

(ns buber
  (:require [babashka.tasks :as tasks]))

(defn -main [task & args]
  (binding [*command-line-args* args]
    (tasks/run (symbol task))))

and then put your bb.edn in META-INF in the uberjar

You will need the master version that was just pushed

thanks

ohhh this is excitingggg

....I just tested it on windows and yes, it works as expected 👍

copy /b bb.exe + foo.jar mybb.exe

C:\foo>mybb.exe 1 2 3
("1" "2" "3") 6

what a time to be alive! (™️) 😄

So if you're building some babashka CLI app, I believe you'll be able to generate native binaries for all the combinations of OSs (mac, linux, windows) and platforms (arm, amd64) in matter of seconds. No compilation whatsover. Looking forward to see how fast such CI pipeline can run 🤞.

(better late than never...) So I'm looking at this now, for our usecase we have a seperate bb.edn with all the tasks defined in it; is it going to be preferable to refactor it to be a babashka.cli program instead? > and then put your bb.edn in META-INF in the uberjar I'm new to java packaging, so while I understand what this means I'm lost on how to do it 😅

I've been debating refactoring it to babashka.cli anyway, since we'd benefit from the extra additions, so having to do so to make this simpler is no trouble 🙂

@U043RSZ25HQ So how to deal with tasks: • Add bb.edn to META-INF/bb.edn E.g.:

{:paths ["resources"]}

mkdir -p resources/META-INF
cp bb.edn resources/META-INF

(ns buber
  (:require [babashka.tasks :as tasks]))

(defn -main [task & args]
  (binding [*command-line-args* args]
    (tasks/run (symbol task))))

bb uberjar tasks.jar -m buber 

and then proceed as documented with the self-contained jar

Ah I see, that clears that one up, thanks 🙂

I added docs about tasks in self-contained binaries here now: https://github.com/babashka/babashka/wiki/Self-contained-executable#tasks

I’ve been working with this approach today. I can even quickly create standalone binaries on github actions for all platforms on a single builder instance. Very nice. The only issue I’m running into now is that MacOS binaries need to be signed/notarized or they will give the usual annoying warning / message.

@U09N5N31T the bb binary itself isn't notarized. you won't have any problems with this if you download the binaries via a terminal. just don't download them via a browser and unzip them via finder

@U09N5N31T I've seen something similar on windows & avast antivirus. Once avast saw a new binary, it insisted on having it analysed on first execution. I have to wait a couple of 10s of seconds, but once it finished, it was working normally.

Btw how many different binaries did you build and how quick that process was? seconds?

it is only when you go through Finder's unzip, that macOS will think "wtf, a binary, let's set some attributes so nobody can run this" you undo that using:

sudo xattr -c ./my-binary

the build process is as fast as you can run cat on two files

Ooh good to know this is hooked into the browser download.

I am using etoain with bb

Regular etaoin works with bb now

Nice! Thank you :face_with_cowboy_hat:

By "handle it" do you mean ignore it or react to it? You can add a shutdown hook with babashka:

(.addShutdownHook (Runtime/getRuntime) (Thread. (fn [] ...)))

Thanks! This solved it. I guess I just had not properly done this before and didn’t know how to capture it

I just attempted to repro... I feel like there was maybe a time when bb did this - are you running the latest version, and do you have a specific repro? Using bb repl and doing (def x #{ 1 2 3}) I get #'user/x - could maybe be a namespace thing?

ah yeah it seems I'm on a rather old version at home 1.0.168 and explains why I see this here and not at work where I have a release from just a few months ago