Fork me on GitHub
#babashka-sci-dev
<
2022-03-23
>
cap10morgan16:03:53

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

borkdude16:03:33

yeah, it's activated with the bb org now

👍 1
borkdude16:03:41

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

borkdude16:03:24

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

👍 1
borkdude16:03:33

thanks a lot!

cap10morgan16:03:45

no problem, it was fun 🙂

borkdude16:03:59

Do you have access to an M1 machine?

borkdude16:03:48

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.

cap10morgan16:03:38

I'll build it and give it a shot

borkdude16:03:16

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

borkdude16:03:40

@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)"]))}}}

borkdude16:03:55

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

lispyclouds16:03:01

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

borkdude16:03:19

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

borkdude16:03:36

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

borkdude16:03:05

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

borkdude16:03:05

@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?

cap10morgan16:03:51

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.

cap10morgan16:03:09

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

borkdude16:03:04

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

cap10morgan16:03:26

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

borkdude16:03:00

I think that makes sense

borkdude16:03:25

this is very cool

😁 1
borkdude16:03:56

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

💯 1
borkdude16:03:01

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

cap10morgan16:03:38

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

cap10morgan16:03:27

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.

cap10morgan16:03:37

happy to dive back into that if you'd like

borkdude16:03:00

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

cap10morgan16:03:17

cool. I'll start with uberjar then

borkdude16:03:12

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

borkdude16:03:51

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

1
borkdude17:03:32

what happens if you emit some code like

pod/babashka/go_sqlite3.clj
into the uberjar with the contents:
(load-pod 'org.babashka/go-sqlite3 "0.1.0")
Perhaps when loading that namespace that namespace will be replaced by the pod namespace

cap10morgan17:03:26

yeah interesting

borkdude17:03:36

That works :)

borkdude17:03:39

(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)"])

borkdude17:03:46

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

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

borkdude17:03:01

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

cap10morgan17:03:11

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

borkdude17:03:11

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

borkdude17:03:30

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

borkdude17:03:40

That seems a lot simpler

borkdude17:03:31

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

cap10morgan17:03:13

yeah, that could be pretty nice

borkdude17:03:27

yeah roughly

cap10morgan17:03:39

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

cap10morgan17:03:50

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

borkdude17:03:39

potentially yes

cap10morgan17:03:37

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

borkdude17:03:08

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

borkdude17:03:27

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

borkdude17:03:48

(similar idea, thinking out loud)

cap10morgan17:03:55

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

borkdude17:03:35

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

👍 1
cap10morgan20:03:19

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

cap10morgan20:03:23

PR coming shortly

cap10morgan20:03:24

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

cap10morgan20:03:07

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)

cap10morgan20:03:11

assuming you can connect stdio or a socket across that emulation layer...

cap10morgan20:03:15

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

borkdude21:03:19

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

👍 1