:rolling_on_the_floor_laughing: that also happens to be the AKC registered name for my Yorkie :rolling_on_the_floor_laughing: I have to abbreviate it because "Peanut Butter Cup *B*lue*B*erry *S*un*S*hine *H*ead" wouldn't fit on the pen/paper form :rolling_on_the_floor_laughing: I love it!!!!

BlueBerry SunShine Head could be the unofficial name of the pod

Hello, have some issues here

user=> (pods/load-pod 'epiccastle/bbssh "0.1.0")
Downloading pod epiccastle/bbssh (0.1.0)
Successfully installed pod epiccastle/bbssh (0.1.0)
java.lang.Exception: Unable to resolve classname: java.lang.ref.Cleaner [at <repl>:22:3]

@U1QQJJK89

Ooh!

I see it

the version requirement was in the API docs

should work partially on 163 (everything but streaming support from a SshProcess to a babashka.process). The change to make that work lands in 164

I you need 164 early its here https://github.com/babashka/babashka-dev-builds/releases/tag/v0.10.164-SNAPSHOT

Thanks

Check out neil new: https://github.com/babashka/neil It works with any deps-new template: https://github.com/seancorfield/deps-new (Sorry for the Slack spam, I don't know how to remove the previews on my phone 😅)

Ah, I should have guessed that neil would have one.

How are the default args static?

right! I was looking at the bb integration, I guess they are not if I use the cli/parse-args directly

The gist is that the certificate offered up by the source site (github in this case) is not 'verifiable' (in the sense that its certification path doesn't roll up to a trusted certificate in substrate JVM's keystore). My experience with this is a workplace that does network traffic interception (so the traffic is signed with an internal cert, not the 'real' cert). Assuming you have a JVM keystore with the appropriate certs (which is a much longer conversation, but is fairly well-documented on SO and the like), you can instruct bb (really the substrate JVM it uses) to use that keystore by specifying the trustStore property:

; deliberately broken
>bb -Djavax.net.ssl.trustStore=nocerts "(slurp \"\")"
----- Error --------------------------------------------------------------------
Type:     javax.net.ssl.SSLHandshakeException
Message:  PKIX path building failed: ....

; with the right cert in place
>bb -Djavax.net.ssl.trustStore=withcerts "(slurp \"\")"
"{\n  \"args\": {}..."

It's having the cert chain verification issue as it tries to download the pod. That pod is hosted on github so it's having the problem connecting to http://github.com via https. In the worst case if you cant fix your local keystore you can download the pod and install it manually. What OS and arch are you on? You could take the pod archive from matching :artifact/url here: https://github.com/babashka/pod-registry/blob/master/manifests/org.babashka/postgresql/0.1.1/manifest.edn extract out the listed :artifact/executable from it, and store it in ~/.babashka/pods/repository/org.babashka/postgresql/0.1.1/<MACHINE>/<ARCH>/pod-babashka-postgresql and then babashka would see it as already installed and use that instead of downloading it. On my machine it's /home/crispin/.babashka/pods/repository/org.babashka/postgresql/0.1.1/linux/x86_64/pod-babashka-postgresql

Also are you running by any chance in an alpine or something similar container?

I'm running in a mac of my workplace and a netskope client is installed. As Bob well guessed, this was causing the certificate problems. I just managed to disable it for a moment (it restart by itself automatically) and my script could download the postgres pod manifest. Now it's working well again. Thank you all for your help 🙂