might be that @karol.wojcik realised that on #holy-lambda lambda, but I'll let him explain (explaining out leaves mental tracks :))

I don't know much about babashka. I've used very basic functionality of it to speedup docker builds in my company. @viesti said that babashka can read namespaces from .jar file as well, so maybe it would work that way. Still though don't know how to provide .jar dependencies to babashka.

@karol.wojcik It depends what kinds of dependencies. Not all Clojure dependencies are compatible with bb. So that's why I asked the above question.

You can run jar files with bb -cp foo.jar -m foo for example

Thanks. I can see that clojure.lang.RT is not supported.

That is correct, RT is an implementation detail of Clojure. https://ask.clojure.org/index.php/10303/interop-clojure-pattern-clojure-consider-adding-iter-clojure?show=10305#a10305

I will create a following patch:

#?(:bb
   (defn- process-interceptors
     [mixin payload type]
     (if-let [interceptors (seq (:interceptors mixin))]
       (loop [interceptors interceptors
              result payload]
         (if-not (seq interceptors)
           result
           (recur (rest interceptors) (if-let [interceptor (type (first interceptors))] (interceptor result) result))))
       payload))
   :clj
   (defn- process-interceptors
     [?mixin ?payload ?type]
     (if-let [it (some-> ?mixin :interceptors clojure.lang.RT/iter)]
       (loop [result ?payload]
         (if (.hasNext it)
           (recur
            (if-let [interceptor (some-> (.next it) ?type)]
              (interceptor result)
              result))
           result))
       ?payload)))

yeah that makes sense

You can suggest that you need RT for this iter method in that issue, it's pretty much the nr 1 reason why people depend on RT...

Ok. Babasha fails on including jsonista 😞

----- Error --------------------------------------------------------------------
Type:     java.lang.Exception
Message:  Unable to resolve classname: jsonista.jackson.DateSerializer
Location: jsonista/core.clj:50:3

----- Context ------------------------------------------------------------------
46:   jsonista uses Jackson Databind while Cheshire uses Jackson Core. In our
47:   benchmarks, jsonista performs better than Cheshire (take look at
48:   json_perf_test.clj). On the other hand, Cheshire has a wider set of features
49:   and has been used in production much more."
50:   (:import
      ^--- Unable to resolve classname: jsonista.jackson.DateSerializer
51:     (jsonista.jackson
52:       DateSerializer
53:       FunctionalKeyDeserializer
54:       FunctionalSerializer
55:       KeywordSerializer

babashka has cheshire.core, not jsonista

currently

Will it change in future?

Ok I will just use reader conditionals to use cheshire instead

🙂

Well, I probably won't remove it since that will be breaking, but perhaps add more options later, not sure.

To save you some time, what other deps are you using?

Then I can tell you if that will work or not

It's all I'm using.

Probably in 30 minutes I will have babashka example working.

nice!

@borkdude May i ship babashka with holy-lambda?

Sure

Got it working

@borkdude What is some babashka internal thing that I can prove it's running on babashka?

Ok will use babashka.main.version 😄

Huh. babashka.main is not available in scripts? 😮

You can do (System/getProperty babashka.version) (sorry typing on phone)

Thank you! Got this working 🙂 https://bdsa1uru44.execute-api.eu-central-1.amazonaws.com/Prod/

May I please announce the new version here as well @borkdude? Just once to let people know about babashka runtime :)

Of course!

Thank you so much 🙂

It's not so big 😄 But this is great candidate: https://github.com/FieryCod/holy-lambda/blob/master/modules/holy-lambda-template/resources/leiningen/new/holy_lambda/Makefile

Ah yes that is the one I was thinking about, reading tutorial.

There is not much yet in tutorial. Would love to work on it more, but my time is very limited 😞

Just checked babashka tasks. @borkdude I would love to have them in the project. Is it possibile to provide tasks in jar then somehow automatically merge user and jar tasks?

Right now bb tasks is only supports in bb.edn

Ok got it. Will manualy copy bb.edn from one repository to another.

I'm moving from an uberscript to an uberjar to make use of pods in a bb-based tool. Building with:

bb uberjar clawe.jar -cp $(clojure -A:remove-clojure -Spath) -m clawe.core

I can take a shot at a reproduction or a PR if it's helpful - not sure what the expected behavior is

@UGNFWPPGF you should set the classpath before the uberjar command probably

bb -cp $(clojure -A:remove-clojure -Spath) uberjar clawe.jar  -m clawe.core

----- Error --------------------------------------------------------------------
Type:     java.lang.Exception
Message:  File does not exist: uberjar

I tried that first to match the docs, but i get this error

ok, try this:

bb --classpath server/src --uberjar foo.jar

this is the old style

clearly something is wrong, please add to the issue

and PR is welcome to fix it

that seems to build properly, and more reasonably sized - i'm seeing a number of warnings for clashing jar items, which is interesting

{:warning "clashing jar item", :path ".cpcache/1246900521.cp", :strategy :noop}
{:warning "clashing jar item", :path ".cpcache/0DF01609C7D30D4D8B3579B5256F3E83.libs", :strategy :noop}
{:warning "clashing jar item", :path ".cpcache/1246900521.basis", :strategy :noop}
...

try removing the jar file before uberjaring again

It could also be a strange path being built on my part - when i run

bb -cp src/clawe --uberjar clawe.jar -m clawe.core

this is great - the uberjar is at least as fast as the uberscript

bb clawe.jar hello  0.11s user 0.03s system 102% cpu 0.139 total
vs
bb clawe-script.clj hello  0.12s user 0.05s system 103% cpu 0.160 total

thanks for the debugging help @borkdude!

ok. I see the command line parsing in the tests is different from the help

I figured out why it was adding everything - my clojure -Spath had a few empty entries in it :: (`src::/home/russ/russmatney/ralphie/src:/etc` ), which seemed to add the entire current directory

in the tests it accepts --classpath as an argument to the uberjar task

oh that's another bug then probably

please comment all your problems to the issue

will do!

Issue updated - the new info is that it looks like the 'blanks' in the classpath are coming from the classpath-overrides

{:aliases
 {:remove-clojure
  {:classpath-overrides
   {org.clojure/clojure          nil
    org.clojure/spec.alpha       nil
    org.clojure/core.specs.alpha nil}}}
==> resulting path:
src::/home/russ/russmatney/ralphie/src:::/home/russ/.m2/repository/cheshire/cheshire/5.10.0/cheshire-5.10.0.jar:/home/russ/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.10.2/jackson-core-2.10.2.jar:/home/russ/.m2/repository/com/fasterxml/jackson/dataformat/jackson-dataformat-cbor/2.10.2/jackson-dataformat-cbor-2.10.2.jar:/home/russ/.m2/repository/com/fasterxml/jackson/dataformat/jackson-dataformat-smile/2.10.2/jackson-dataformat-smile-2.10.2.jar:/home/russ/.m2/repository/tigris/tigris/0.1.2/tigris-0.1.2.jar

@UGNFWPPGF Note that you can now also set the classpath in bb.edn under :paths

but we should still fix this regardless

gotcha - i'll move over to use that