Fork me on GitHub
#babashka
<
2022-05-09
>
Krisztián Ádám10:05:08

Hi, I noticed that most (or all) pods don't have releases for linux/aarch64, even tho babashka itself does. (I keep running into this issue when I copy my scripts to a raspberry) I was wondering what's the main reason/limitation behind this?

borkdude10:05:44

@adamkrisz The main reason/limitation is people not having asked for those so we didn't put in the effort yet

borkdude10:05:57

the aws pod has aarch64 and so do some others, but not all

borkdude10:05:29

Please create an issue in the corresponding pod repository

Krisztián Ádám10:05:17

I see, thanks! (also good to hear 😄)

borkdude10:05:51

We rely on #circleci for aarch64 support - as long as they offer this, we can add support to pods

borkdude11:05:44

@adamkrisz Thanks for the issue. Meanwhile you could also try out #nbb if you don't mind using Node.js - it is a babashka variation for Node.js and can run any Node.js library including playwright, which is an excellent browser testing framework. Here is an example of that: https://github.com/babashka/nbb/tree/main/examples/playwright

borkdude11:05:08

I assume you're using the etaoin pod for browser testing, right?

borkdude11:05:20

If you want you can also try to work on the aarch64 support yourself using a PR, to speed things up

borkdude11:05:34

it's mostly copy pasting things from other pods

Krisztián Ádám11:05:48

oh yeah, I actually did exactly that as a workaround! Thanks for you excellent work btw 😄

Krisztián Ádám11:05:32

I also had problems with the postgressql pod a while back, but I see it has aarch64 releases now

Krisztián Ádám11:05:35

I'll try to open a PR then, I was just looking into how it got solved for the other pods

👍 1
borkdude15:05:07

@adamkrisz I just pushed the aarch64 and updated the manifest, so you should now be able to use the pod in babashka using version 0.1.0. You might have to clear your ~/.babashka/pods directory first.

🎉 1
borkdude15:05:23

I decided to not release a new version but update the existing one just with the aarch64 binary

borkdude21:05:27

seems good to me!

lread21:05:11

Coolio. I’ll follow up with a PR.

lread21:05:04

Did we ever look at making etaoin itself bb friendly? Or was that not practical?

borkdude21:05:42

That should theoretically be possible I guess? Since it's just an http client basically?

lread21:05:00

Yeah… had a little look. It uses clj-http. I guess we’d need to switch that to clj-http-lite?

borkdude21:05:36

to make it more graal friendly

borkdude21:05:50

that one is what the pod uses

borkdude21:05:24

maybe fork it and then try it out :)

borkdude21:05:14

there is also this thing: https://github.com/tatut/clj-chrome-devtools but that is slightly different

borkdude21:05:17

it works with bb too

borkdude21:05:37

it would be great to have etaoin from source, so we could deprecate the pod

lread21:05:59

I’ll go raise an issue over at etaoin to see if there is interest in becoming babashkable directly.

lread21:05:27

(thanks for clj-chrome-devtools pointer too, did not remember that one!)

borkdude21:05:46

ok, and if he isn't interested, then we could maintain a fork like https://github.com/grzm/awyeah-api is doing for aws-api

lread21:05:59

sounds good

borkdude21:05:04

yeah, I wanted the merge conflict to be small

borkdude21:05:15

I'm regularly merging from upstream

lread21:05:45

aha, makes sense

borkdude08:05:55

A very short term thing is adding the execute method to the etaoin pod. I'm probably releasing a new version soon since there was just another PR.

lread13:05:29

Thanks borkdude! Since we have interest 🎉, I think I’ll focus on making etaoin bb friendly instead.

borkdude13:05:08

this would be great, one less pod to maintain :)

lread13:05:07

And we could use the bb compatible badge in one more place!