Fork me on GitHub

@bhurlow I have three approaches now and I choose one depending on the context: 1) Shelling out to the aws cli (example with spire 2) Building the request myself with a fork of aws-api 3) Waiting for someone else to do this and keep things running via the JVM until that point Many things can be done with 1), but it is not perfect and has a (brittle) dependency on the aws cli tool (and therefore a python installation) 2 requires a lot of hand work and understanding of the AWS http requests. I haven’t done this from Babashka yet. Only directly with Graalvm, but I’m guessing it could work with Babashka too. 3 is wishful thinking, but will probably happen at some point


(someone else could also be my future self :))


maybe there could be a pod-babashka-aws


Yeah I was also thinking maybe there could be a generic clj dependency pod so you can require any dep via Babashka (at the cost of boot time). Maybe this could even be done with a reusable jvm process (wishful thinking)


(disclaimer: i haven’t written a pod yet, so not really knowing what I’m talking about)


the intention of a pod is an executable that acts as a library to babashka for stuff that cannot or is hard to implement as interpreted code - while still having great startup time


so if the cognitect/aws already works with graalvm, then that might be an option


shelling out to a JVM kinda defeats the purpose, you might as well write the whole thing with clojure at that point


It only defeats the purpose if it will always hit the jvm. E.g. if your babashka script has many other paths or has to do some kind of validation before calling the jvm it definitely doesn’t defeat the purpose


As an example I have create a babashka script for starting an application. Only the validation code can run with Babashka, the actual application has to be done via a JVM process. However considering the validation of parameters can safe you a lot of time, it is beneficial to do this in Babashka first before shelling out to JVM


However, the JVM pod i’m talking about is nothing more than an idea. So maybe it doesn’t work well in practise or maybe I’m missing things


If that's the case, then it might make sense 🙂


babashka can also already talk to an nREPL session, which might also work


or socket REPL


Ah that's cool so in theory an approach like this could work with babashka


Think so yes, although I've never really looked at prepl


Here's an example of how to talk to an nREPL:


Not sure if all classes are available in babashka, but other than that nothing too special I think


clojure.lang.ExceptionInfo: Unable to resolve classname:


could add 😉


apart from that, the code at least loads: $ lein bb /tmp/client.clj.txt #'clojure.scripting.client/-main


Added the class on master. Feel free to experiment 😉

babashka 3

I think a pod-babashka-aws backed by a JVM prepl could be useful


Why not use clojure in that case?


Because it could be a persistent jvm process in the background


And how about implementing that pod in Python using the normal AWS SDKs?


I would like to use Clojure and this seems doable


And for the future my hope would be to replace the pod with a native babashka library with the same API


Maybe start as pod-adgoji-aws or something


and when it's mature it can become "official"


yeah sounds good. I’ll test some of my assumptions before making it a pod


@jeroenvandijk awesome thanks for recapping this! it now makes a lot of sense. IMO the aws-api lib is far superior to shelling out due to its data-driven nature and discoverability of methods etc. As you mention in the ticket there, decoupling the platform specific operations may provide some additional value for that project and let it work in the Graal/Babashka env