Fork me on GitHub
#babashka-sci-dev
<
2022-03-21
>
cap10morgan17:03:00

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?

borkdude17:03:30

@cap10morgan are you testing on m1?

borkdude17:03:50

from a JVM, not from bb right?

cap10morgan17:03:58

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

cap10morgan17:03:16

I'll just run it under rosetta for now then

borkdude17:03:16

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

borkdude17:03:21

yeah that's a safer bet

👍 1
borkdude17:03:06

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

borkdude17:03:26

eh no scratch that, it was linux aarch64

cap10morgan17:03:52

ohhh... you had me thinking you were using some early graal mac/arm64 stuff 🙂

cap10morgan17:03:51

oh nice. getting close!

cap10morgan18:03:21

@borkdude Should we support an optional :args param for local pods?

borkdude18:03:39

What's the use case for that?

cap10morgan18:03:28

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

borkdude19:03:58

usually that shouldn't be necessary, there is BABASHKA_POD=true which is set when a binary runs as a pod

borkdude19:03:18

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

borkdude19:03:51

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

borkdude19:03:12

maybe that test can use that convention too

borkdude19:03:29

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

cap10morgan19:03:41

OK I pushed a couple tests

cap10morgan19:03:50

and marked the main PR ready for review

borkdude19:03:27

we first need the pods PR merged right?

cap10morgan19:03:51

oh, and I need to test uberjars too

borkdude19:03:56

also uberscripts :)

borkdude19:03:22

for uberscripts we probably want to so something special, but I can fix that post-merge as well

cap10morgan19:03:51

looks like a bb executable isn't in PATH in CI

borkdude19:03:07

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

borkdude19:03:30

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

cap10morgan19:03:53

that's how I made it able to run test-resources/pod.clj as a pod w/ just the path

cap10morgan19:03:11

gave it a shebang of #!/usr/bin/env bb

borkdude19:03:48

do you have a question?

borkdude19:03:54

or is this just info

cap10morgan19:03:36

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

👍 1
borkdude19:03:38

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

cap10morgan19:03:47

I think so, yeah

borkdude19:03:19

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

👍 1
borkdude19:03:49

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

borkdude19:03:58

since that should now be equal

borkdude19:03:23

or maybe you can sort that out on your end

cap10morgan19:03:42

probably just merge commit vs. former branch head commit

cap10morgan19:03:47

I'll see if that resolves it

borkdude20:03:30

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

borkdude20:03:15

but other than that, it looks good

borkdude20:03:04

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

borkdude20:03:10

eh I mean, merge with the declarative-pods branch

borkdude20:03:21

oh and there's a failing test

cap10morgan21:03:02

uberjar seems to work

cap10morgan21:03:12

both registry and local

cap10morgan21:03:30

merging w/ declarative-pods got rid of the pods submodule diff

cap10morgan21:03:52

oh but uberjar only works if it's still in the project root :grinning_face_with_one_large_and_one_small_eye:

cap10morgan21:03:09

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

borkdude21:03:48

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

cap10morgan21:03:53

not sure. it's not really a "path", so kind of abuses that attribute even if it does work

cap10morgan21:03:22

right now the local pods path assumes you're pointing it at something the system can execute as a process directly

borkdude21:03:54

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

borkdude21:03:59

and make that executable