babashka-sci-dev 2022-05-13

Isn't that why we made the prepare subcommand?

oh yeah, probably. I forgot we did that haha. I didn't adopt it where I was doing that. 😆 I'll give it a try!

looks like prepare tries to run local pods too. probably b/c it downloads pods and tries to cache their describe metadata. hmm...

borkdude13:05:29

yes, you implemented that all, haha

cap10morgan13:05:36

yep

cap10morgan13:05:08

just trying to think if it's worth changing it / adding a flag / whatever for the download-only use case

borkdude13:05:39

what's the problem with caching?

cap10morgan13:05:07

if you're just trying to download, sometimes it's handy (e.g. docker images) to ignore the local pods in case they aren't available at that path. which is fine if you're just trying to download non-local pods.

borkdude13:05:02

we could add a try/catch around the caching?

cap10morgan13:05:14

Yeah

borkdude13:05:16

or what's wrong with actually executing them?

cap10morgan13:05:25

nothing when they exist at the path in the config 🙂

cap10morgan13:05:15

on the flip side, it's nice to cache that metadata in the docker image too. I'll have to play around w/ it and think about it a bit more.

borkdude13:05:19

maybe we should check if the pod exists before executing it and else just do nothing?

borkdude13:05:25

cap10morgan13:05:45

yeah, maybe log a warning but continue on w/ downloading or something

borkdude06:05:58

I think deep merging at the CLI is something we need for other use cases, eg setting the mvn local repo too

borkdude09:05:55

@cap10morgan I like what shadow has done here with naming: --config-merge makes the intent very clear https://shadow-cljs.github.io/docs/UsersGuide.html#config-merge

👍 1

cap10morgan19:05:30

OK I think I ran into an issue w/ local pods in uberjars. Currently the code puts the metadata cache into a .babashka dir in the same parent dir as the bb.edn file (i.e. our idea of a project-specific .babashka dir). Which, in the case of a JAR, is the META-INF inside the .jar file. So then it tries to write out the metadata to a file in there and throws a FileNotFoundException (which I assume is really a "I can't write to a file there" exception). The simplest fix might be to just test for ability to write to the file there and not try to cache the metadata if we can't. So no local pod caching in uberjars. And then we can address caching when / if we build the option to pull pods into the uberjar too.

borkdude19:05:09

sounds good

👍 1

2022-05-13

Channels