This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-21
Channels
- # announcements (13)
- # babashka (63)
- # babashka-sci-dev (64)
- # beginners (37)
- # biff (1)
- # calva (10)
- # cider (7)
- # clj-kondo (15)
- # cljsrn (6)
- # clojure (26)
- # clojure-dev (10)
- # clojure-europe (34)
- # clojure-france (9)
- # clojure-nl (2)
- # clojure-norway (36)
- # clojure-uk (5)
- # clojurescript (142)
- # community-development (1)
- # conjure (3)
- # datalevin (5)
- # datalog (2)
- # datomic (5)
- # events (11)
- # fulcro (40)
- # gratitude (9)
- # guix (32)
- # honeysql (10)
- # jobs (2)
- # lsp (32)
- # malli (15)
- # meander (5)
- # membrane (43)
- # missionary (3)
- # nextjournal (9)
- # off-topic (38)
- # pathom (3)
- # polylith (30)
- # portal (78)
- # programming-beginners (4)
- # quil (6)
- # re-frame (20)
- # reagent (21)
- # remote-jobs (2)
- # shadow-cljs (7)
- # tools-deps (6)
- # xtdb (23)
trying to write some tests for all this but getting an error from the resolver code that it can't find a pod for Mac / aarch64. what makes that fallback on x86_64 usually?
@cap10morgan are you testing on m1?
oh, is it b/c the bb executable itself is x86_64 usually?
makes sense
I'll just run it under rosetta for now then
it does work for the org.babashka/go-sqlite3
pod btw, this was released today for mac m1 ;)
ohhh... you had me thinking you were using some early graal mac/arm64 stuff 🙂
Still have to try this out: https://github.com/babashka/babashka/wiki/Compiling-for-M1
oh nice. getting close!
@borkdude Should we support an optional :args
param for local pods?
well, I noticed it when trying to load the test pod.clj file, which needs the --run-as-pod
arg to go into "pod mode" and thought there might other times you'd want to pass args to pods. the existing load-pod
approach supports that by passing a vector, but currently the declarative approach doesn't have a way to pass anything but the path to the pod executable
usually that shouldn't be necessary, there is BABASHKA_POD=true
which is set when a binary runs as a pod
gotcha
OK I pushed a couple tests
and marked the main PR ready for review
oh, and I need to test uberjars too
for uberscripts we probably want to so something special, but I can fix that post-merge as well
looks like a bb
executable isn't in PATH in CI
that's how I made it able to run test-resources/pod.clj
as a pod w/ just the path
gave it a shebang of #!/usr/bin/env bb
I think so, yeah
I updated the pods repo in branch declarative-pods
and made your PR to merge to that branch
probably just merge commit vs. former branch head commit
I'll see if that resolves it
uberjar seems to work
both registry and local
merging w/ declarative-pods
got rid of the pods submodule diff
oh but uberjar only works if it's still in the project root :grinning_face_with_one_large_and_one_small_eye:
failing test is still the missing bb
binary in CI. need to decide what we want to do there.
not sure. it's not really a "path", so kind of abuses that attribute even if it does work
right now the local pods path assumes you're pointing it at something the system can execute as a process directly