Hello! When I tried to run a babashka script with the relevant babashka/babashka container image, I got an error that (deps/add-deps) couldn't find java. I suppose that this functionality depends on the jvm? Are there any (official) container images that contain both babashka AND the jvm/jdk?
@agorglouk Yes, add-deps depends on the JVM. There are no official images that include the JVM. Easiest would probably be to make your own or grab a JVM image and install bb inside of that
will do that thank you 🙂
..that means NOT running the graalvm-native-compiled babashka in such docker image, right? Ie: running "jar" version of babashka using full-blown jvm.
no?
I mean: yes, it does NOT mean that
> I mean: yes, it does NOT mean that
beauty of logic 🙂
So does that mean that natively-compiled babashka can benefit from having real jvm installed in the same container in that sense, that you will be able to call deps/add-deps?
yes. but... in the optimal case you do this in a pre-final build stage so you don't actually need the JVM at runtime in the image
Interesting. It never occured to me that native bb can use real jvm. I thought that statically compiled (native-image) graalvm binaries don't support class loading... so I still don't see how native bb can use real jvm. (other than "fork javac process and then stare silently on the generated .class file which you unfortunately can't load" 😅 )
babashka add-deps doesn't support class-loading. it just supports running a bb compatible library from mvn, git deps, etc.
same as bb.edn
the reason the JVM is used is that tools.deps is invoked
Oh, I see. Makes sense.
that was gonna be my next question: i'm kinda fighting again with corporate proxies, but this time it gets worse because i do it inside a container. Could you describe in high level all the interdependencies of bb (when using add-deps) in order to understand what processes are being spawned that may need configuration bellow?
(should I start a new thread about this?)
this is used under the hood: https://github.com/borkdude/deps.clj proxy stuff is supported and documented in there
I suspect that all of the bb/jdk/tools.deps/deps.clj/mvn are used together (chained somehow)
yeah I've reached the part that bb calls deps.clj and I've seen the proxy setup of deps.clj
artifact resolution through the proxy works, fetching the dependencies does not so far
it might be far easier to just build an uberjar with your deps and then use that in your container?
yes it would, I'm just trying to build a deeper knowledge around the bb ecosystem 🙂
as far as I remember setting up the proxy in .m2/settings.xml will make it work, the question is why/how is mvn involved in the add-deps process
I'm trying to pass around proxy configuration through environment variables
if you are using mvn dependencies, then mvn is used per tools.deps
I don't do any other magic around this, same as the clojure CLI
ah it seems that the chain is bb -> deps.clj -> tools.deps
deps.clj just spawns a clojure subprocess am I correct?
true
deps.clj is just basically a rewrite of the clojure CLI bash script to clojure itself
and should behave the same way (barring some extra features like proxy support!)