Clojurians Log v2

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?

yeah

from a JVM, not from bb right?

oh, is it b/c the bb executable itself is x86_64 usually?

yes

makes sense

I'll just run it under rosetta for now then

maybe you can fake this by setting the system property yourself?

yeah that's a safer bet

it does work for the org.babashka/go-sqlite3 pod btw, this was released today for mac m1 ;)

eh no scratch that, it was linux aarch64

never mind

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?

What's the use case for that?

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

so normal CLIs can check that env var to see if they are invoked as a pod

but we could support it, I don't see harm in that

maybe that test can use that convention too

the env var wasn't there yet, when that test got written

gotcha

OK I pushed a couple tests

and marked the main PR ready for review

we first need the pods PR merged right?

yep

oh, and I need to test uberjars too

also uberscripts :)

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

correct, we don't use bb to do CI stuff for bb

but we could use the bb uberjar or freshly built bb binary maybe

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

do you have a question?

or is this just info

just info. letting you know why it's suddenly looking for a bb in the path

so we are good with the pods PR but the bb side still needs work, right?

I think so, yeah

I updated the pods repo in branch declarative-pods and made your PR to merge to that branch

I'm not sure why I'm still seeing a diff in the pods submodule though

since that should now be equal

or maybe you can sort that out on your end

probably just merge commit vs. former branch head commit

I'll see if that resolves it

ah yes

still seeing a change in the pods submodule. perhaps you can merge with master

but other than that, it looks good

I'm ok with doing the uberjar and uberscript support as separate PRs

eh I mean, merge with the declarative-pods branch

oh and there's a failing test

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 🤪

failing test is still the missing bb binary in CI. need to decide what we want to do there.

can't you just call "./bb script.clj" ?

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

I guess you can create a temporary bash/.bat wrapper

and make that executable