The single file, what kind of usage does that have?

If you add a deps.edn you can expose your code as a library to others, but if you want to distribute your code more like a CLI tool, you can make an uberscript or uberjar (which is a self-contained zip file). bb uberjar foo.jar

you can also make your tool installable via bbin: https://github.com/babashka/bbin/

there's various other options, but first I'll wait for your reply to learn more

If you just want to write a library that can be used by a babashka code, you don't need to do anything special. 1. Write a normal clojure project 2. Preferrably run your library test suite on both JVM Clojure and Babashka 3. Publish to Github or clojars 4. Use that library from babashka or from JVM Clojure. The answer to your question depends a lot on whether you want to package a library or package a script.

I have some babashka clj files that implement some parsers for business specific file types. I want to make it as easy as possible for others to use these parsers in their own Babashka code. I can create jar files with the JVM Clojure. That works. But always going the way over the JVM Clojure is a long journey. And such JVM Clojure jar files would also require more dependencies, because all the libraries, that Babashka has already included would have to be loaded by the JVM Clojure. So the jar files would depend on them. Every user would need an installation of Clojure. That is a bit against the idea of having the batteries already included. I must say, even when I want to reuse something from JVM Clojure in Babashka, I copy the clj files. I normally don't create jar files, because it feels really heavy to load jar files from Babashka. I don't know if you can follow me. Maybe I am asking something for which Babashka was never meant. Babashka is a scripting language. In a scripting language you normally don't want to load things like shared libraries. But it is so tempting, to use Babashka even a bit like a real programming language. So I wonder if something like shared libraries is possible.

> I want to make it as easy as possible for others to use these parsers in their own Babashka code. This sounds like a library to me. Just add a deps.edn file to your project and then let others use it in their bb.edn file

I don't see why you're even mentioning jar files here

you don't have to push something to clojars or mvn, you can let others use your library as a git dependency

I think, the solution is indeed an uberjar file. So I stored all clj source files in an src folder and created an uberjar with bb uberjar my_lib.jar --classpath src/ . That works. The only thing, that is a bit strange, is that when starting Babashka with a project that depends on that uberjar file, Babashka downloads the JVM Clojure, even if there are no dependencies, at all in that uberjar file. It looks like the mechanism to depend on :local/root jar files needs the JVM Clojure. To me it looks like not intended behaviour of Babashka. Because bb --jar works without the help of the JVM Clojure. It would be consequent if Babashka could also depend on such jar files. But maybe there is something missing in my uberjar. I don't even have a deps.edn and the Manifest is quite empty.

Everything under :deps in bb.edn uses tools.deps via the JVM to resolve dependencies, once. There is no logic to bypass the JVM if you are using :local/root + jar files. I still don't understand why you are creating a jar file from your project. Why not host it on Github so people can depend on it as a git dependency for example?

I want to use Babashka on a test rig. I use a jar file, because it is more handy to have a single file for all my dependencies. The machines have not much network connectivity. I manually have to download each dependency and copy it into the .m2 folder.

ok makes sense

note that you can bypass the JVM deps mechanism by providing the classpath yourself:

bb --classpath foo.jar:bar.jar 

That is a good idea. Thank you! I can even do this in bb.edn. I removed :deps from bb.edn and added the jar file to :paths. That works.

👍

…communicating via bencoded data, IIRC. yes.

yes

Than one more question. Are the pods also native images or are there also general jvms

some are written in golang. I think anything goes ✨

yep, anything. rust, python, whatever :)

Ok great only requirement is i guess a socket which talks bencode right?!

yes, or stdin/stdout

Try babashka.http-client instead

Using babashka.http-client works. Thanks. Any ideas what could be wrong with the curl lib ?

Bb curl instructs curl to write a header file to disk and bb curl then parses this. Apparently it’s not able to write

Got it. Thanks

there was an upstream breakage in curl 8.7.1 recently: https://github.com/curl/curl/issues/13493

Thanks @UMY8HG1HR. I can say that it's not only in Debian, but also in OpenSUSE Tumbleweed that this issue occurs.

I'm also hitting the curl issue on babashka CI in Alpine now :/

And apparently apk doesn't have a way to downgrade?