Fork me on GitHub
#babashka
<
2023-02-24
>
lispyclouds08:02:03

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?

borkdude08:02:25

Use bb uberjar

2
borkdude08:02:59

As written in "the book" ;-)

lispyclouds09:02:23

also on that note any recommendation for pre downloading the pod during the container image build time?

lispyclouds09:02:30

jar runs fine now, just that it downloads the pod on the first run. i have a usual bb.edn which declares the pod

borkdude09:02:11

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

lispyclouds09:02:00

i could do a RUN bb -e "(load-pod ...)" maybe?

borkdude09:02:21

that also works, but then you would need to change your code

lispyclouds09:02:01

would it need a change? this is just to nudge the download

borkdude09:02:36

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)

borkdude09:02:45

+ BABASHKA_PODS_DIR

lispyclouds09:02:54

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

borkdude09:02:19

yes, but tweaking those env vars + pods dir will also take care of that

lispyclouds09:02:41

right, will poke around

lispyclouds09:02:19

seeing @U054AT6KT’s talk yesterday, quite iffy to ask him docker things 😛

borkdude09:02:11

#C01UQJ4JC9Y uses docker too ;)

borkdude09:02:17

and it has support for that stuff too

borkdude09:02:53

but the 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?

lispyclouds09:02:57

yeah these are some good sources to read up on

borkdude09:02:19

or would you build on amazon?

lispyclouds09:02:40

foe the workshop planning a simpler, self contained thing which can be reasoned about and make better things later

lispyclouds09:02:53

this would be built locally

lispyclouds09:02:33

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

lispyclouds09:02:02

this works:

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"]

pizzaspin 1
jmglov09:02:58

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. 😉

jmglov09:02:34

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.

👍 2
jmglov09:02:19

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. 😉

lispyclouds09:02:25

yeah im not building the image for a lambda anyways, this is more about a general use case

jmglov09:02:10

Makes sense. 🙂

borkdude09:02:15

Now open for registration! Friday 17th of March 8:00 EST babashka workshop with https://twitter.com/lispyclouds! https://clojure.stream/workshops/babashka

❤️ 2
pizzaspin 1
Matthew Twomey17:02:39

Is there a “helper” out there to natively compile (graalvm) a babashka script in a single / small number of steps?

borkdude18:02:19

There's this to bundle bb + a program into one executable: https://github.com/babashka/babashka/wiki/Self-contained-executable

👍 2
borkdude18:02:16

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

borkdude18:02:24

or via #C0400TZENE7

4
Matthew Twomey18:02:13

Ok - thanks, will think on my options.

borkdude18:02:38

The disadvantage of producing your own graalvm binary or bundled bb binary is that you have to produce one for every OS + architecture

Matthew Twomey18:02:28

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.

Matthew Twomey18:02:06

(want to make it as “one-shot” as possible for them)

borkdude18:02:24

ok, for brew I think you might want to look at how neil is published

Matthew Twomey18:02:49

Yep! I was just looking at that as it was used as the example in the bbin repo

borkdude18:02:56

ah yes, you can ask your devs to install bbin from brew:

brew install babashka/brew/bbin
and then ask them to do:
bbin install your-script-clj

borkdude18:02:29

installing bbin will also install bb automatically

Matthew Twomey18:02:41

Ok - thank you, I’m going to try this route.