@borkdude I unfollowed the pods repo in my CircleCI account so you can follow it from yours

yeah, it's activated with the bb org now

thanks a lot! I didn't realize we had no CI for that

sure thing!

I've merged the PR now, additional fixes/features can happen in future PRs

thanks a lot!

no problem, it was fun 🙂

Do you have access to an M1 machine?

I do

I think it's worth testing if intel pods work with the M1 version of babashka. I'll try it myself too, but if they work, then I think adding a fallback mechanism for macos/aarch64 to macos/amd64 might make sense.

yep

I'll build it and give it a shot

that would save us a lot of trouble with re-compiling all those pods... while having no M1 CI available, that gets tedious

yeah

@cap10morgan This seems to work with the fallback in place:

{:pods {org.babashka/go-sqlite3 {:version "0.1.0"}}
 :tasks {:requires ([pod.babashka.go-sqlite3 :as sqlite])
         create-db {:task (do (sqlite/execute! "/tmp/foo.db"
                                               ["create table if not exists foo (the_text TEXT, the_int INTEGER, the_real REAL, the_blob BLOB)"]))}}}

I'll make a PR and let you review it ;)

great! 🙂

https://github.com/babashka/pods/pull/46

Just chiming in for the Go pods, we can produce aarch64 mac binaries without the arm CI 😄

That's great :) Golang is such a neat language to produce pods!

But it already seems to work with Rosetta2 for now :)

I wonder what other cool golang libraries we could expose as pods

we have https://github.com/avelino/awesome-go to cherry pick 😄

@cap10morgan While I said this in #babashka : > Also, when you declare the pods in your bb.edn, you no longer have to use load-pod in your code, the pod is automatically loaded whenever a related namespace is required. I wondered, do we check if a pod has already been loaded? E.g. if you require multiple namespaces related to the same pod, is the pod started only once?

I believe so b/c it shouldn't even hit the load-fn at that point. Instead it should see that it already has that namespace loaded.

But let me know if you observe behavior to the contrary! 🙂

Ah, because when you load one namespace the other ones are automatically defined and then you no longer hit load-fn, right?

yes. and I am 99% sure I tried it and saw it behave that way too 😉

I think that makes sense

this is very cool

It always feels good when you can close an issue if you've waited long enough for a better solution: https://github.com/babashka/babashka/issues/1065

Guess we can close https://github.com/babashka/babashka/issues/863 too huh?

Done. Should we still go for :pod/version? But what about :path... :pod/path? Blegh

I think they're OK as-is. Next up is probably uber(jar|script) support?

Yeah

I played around with pulling the bb.edn into the jar a little, but it needed a bit more work. I think mostly just accessing it differently (i.e. as a stream) once in the jar.

happy to dive back into that if you'd like

yeah, sounds good. I could take a look at the uberscript, if you don't beat me to it. I have some other stuff to do first

cool. I'll start with uberjar then

for the uberscript, we already hacked the load-fn. and we could "emit" a load-pod into the uberscript similar to when we load the pod in bb now

perhaps that approach would also work for the uberjar btw...

what happens if you emit some code like

pod/babashka/go_sqlite3.clj

(load-pod 'org.babashka/go-sqlite3 "0.1.0")

yeah interesting

That works :)

(ns script
  (:require [pod.babashka.go-sqlite3 :as sqlite]))

(sqlite/execute! "/tmp/foo.db"
                 ["create table if not exists foo (the_text TEXT, the_int INTEGER, the_real REAL, the_blob BLOB)"])

(ns pod.babashka.go-sqlite3
  (:require [babashka.pods]))

(babashka.pods/load-pod 'org.babashka/go-sqlite3 "0.1.0")

So maybe that approach would work for both the uberscript and uberjar

I can try that out first and see if it works for both

@cap10morgan Another approach could be that we would offer a programmatic interface to declare pods

So we copy the bb.edn part to a call to that at the beginning of the uberscript

That seems a lot simpler

(babashka.pods/add-pods '{:pods {...}})

or so

extract this to a separate fn, roughly? https://github.com/babashka/babashka/blob/e6022867996540f0afa2844caa57a6e9b3c903e1/src/babashka/main.clj#L794-L796

yeah, that could be pretty nice

yeah roughly

except take the thing from @common/bb-edn as an arg

that sounds perfect for uberscripts, but I wonder if having the bb.edn in the uberjar would pay dividends in other areas?

potentially yes

might be simpler too (vs. generating some code that has to wrap the main fn that calls this new add-pods)

yes

Maybe, for standalone scripts, we should support some way to inline the entire bb.edn in a script

(babashka.config/set-config! '{:pods ... :deps ...})

(similar idea, thinking out loud)

yep, that would be nicely consistent with the potential uberjar approach

yeah, btw, in uberscripts and uberjars the :deps component should not be processed anymore since all deps should already be there

got it working in uberjars (w/ the "store the bb.edn in the jar" approach)

PR coming shortly

might make sense to (provide an option to) download every os/arch pod variant into the uberjar too

megajar

another crazy idea: if you have qemu in your path, we fall back to running the linux/x86_64 pod w/ it as a last resort 😈 (hello BSD, etc. support)

I'll stop there for now, but let me know if you'd like me to dive into uberscripts too, @borkdude

Thanks! Yeah, embedding the pods into the uberjar is something I've considered as well... dunno, let's consider that later ;)