This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # babashka (47)
- # beginners (38)
- # biff (21)
- # calva (12)
- # cider (2)
- # clj-kondo (25)
- # cljsrn (4)
- # clojure (14)
- # clojure-berlin (2)
- # clojure-conj (1)
- # clojure-dev (24)
- # clojure-europe (84)
- # clojure-italy (8)
- # clojure-nl (1)
- # clojure-spec (1)
- # clojure-sweden (2)
- # clojure-uk (2)
- # clojurescript (34)
- # clr (3)
- # community-development (1)
- # cursive (12)
- # datalevin (8)
- # datomic (5)
- # defnpodcast (2)
- # dev-tooling (1)
- # etaoin (4)
- # events (3)
- # fulcro (23)
- # graphql (3)
- # honeysql (6)
- # hyperfiddle (45)
- # lsp (37)
- # malli (1)
- # missionary (1)
- # nbb (18)
- # podcasts (1)
- # reagent (8)
- # reitit (1)
- # releases (2)
- # ring-swagger (1)
- # scittle (78)
- # shadow-cljs (96)
- # vim (7)
- # xtdb (3)
When building an uberjar targeted to be run on bb that has pod(s), what's the recommended way to build it? If I try to use the standard tools.build uberjarring, the ns requires for the pod errors rightly as its not on the classpath. Should I be using a
(load-pod ...) call instead? Or should I be using bb's uberjarring machinery?
also on that note any recommendation for pre downloading the pod during the container image build time?
jar runs fine now, just that it downloads the pod on the first run. i have a usual bb.edn which declares the pod
This is a complicated are you may want to leave out in the workshop. It's best to copy the pod for your OS to a directory and then set
BABASHKA_PODS_DIR to that directory in your lambda.
Perhaps @U054AT6KT can chime in here as well as he has support for this in #C04PSBFMMDJ I think
i could do a
RUN bb -e "(load-pod ...)" maybe?
would it need a change? this is just to nudge the download
You can also do this outside of docker (blambda doesn't use docker I think) with:
BABASHKA_PODS_OS_NAME=Linux (or Mac OS X or any other value returned by Java's os.name property) BABASHKA_PODS_OS_ARCH=aarch64 (or amd64 or any other value returned by Java's os.arch property)
my slight issue there is the build arch and the container arch needs to be the same. triggering the download inside the build env should align all the archs
right, will poke around
seeing @U054AT6KT’s talk yesterday, quite iffy to ask him docker things 😛
load-pod approach should work I think, if you're able to build for the right architecture. e.g. can you build an arm64 docker image on a mac amd64?
yeah these are some good sources to read up on
foe the workshop planning a simpler, self contained thing which can be reasoned about and make better things later
this would be built locally
generally the pattern i follow is let the target arch things be a problem of image builder and tweak it externally instead of the cross product of the binaries and targets
FROM babashka/babashka WORKDIR /opt COPY todos.jar . RUN bb -e "(babashka.pods/load-pod 'org.babashka/go-sqlite3 \"0.1.0\")" ENTRYPOINT ["bb", "todos.jar"]
Holy Lambda is quite awesome and I would highly recommend it for people wanting to run production workloads. My aversion to Docker is a personal problem that I'm working on in therapy. 😉
More seriously, I have a philosophical objection to using a container image on a lambda. It makes things opaque and also huge, and I don't see the benefits of doing it unless your lambda artifacts are so huge that you're running into the 200 MB limit, in which case you have other problems, IMO.
on a side note, https://github.com/jmglov/blambda/pull/5 might interest you @U054AT6KT
But I'm a grumpy old man who's been running Clojure on Lambda since 2015, so take my opinions with a grain of salt. 😉
yeah im not building the image for a lambda anyways, this is more about a general use case
Now open for registration! Friday 17th of March 8:00 EST babashka workshop with https://twitter.com/lispyclouds! https://clojure.stream/workshops/babashka
Is there a “helper” out there to natively compile (graalvm) a babashka script in a single / small number of steps?
There's this to bundle bb + a program into one executable: https://github.com/babashka/babashka/wiki/Self-contained-executable
Although it's interesting, I would avoid it. There's better ways to distribute your programs e.g. via brew with a dependency on bb
Ok - thanks, will think on my options.
The disadvantage of producing your own graalvm binary or bundled bb binary is that you have to produce one for every OS + architecture
Yeah - I agree. I’m just looking for a way to share some bb tools I have written with some nodejs developers I work with. They probably only have the stock jvm on their macs and nothing more Java related. They do use brew though.
(want to make it as “one-shot” as possible for them)
Yep! I was just looking at that as it was used as the example in the bbin repo
ah yes, you can ask your devs to install bbin from brew:
and then ask them to do:
brew install babashka/brew/bbin
bbin install your-script-clj
Ok - thank you, I’m going to try this route.