Fork me on GitHub
#babashka
<
2020-06-26
>
jeroenvandijk08:06:09

@bhurlow I have three approaches now and I choose one depending on the context: 1) Shelling out to the aws cli (example with spire https://gist.github.com/jeroenvandijk/ed497efee4f9528d5cb09ca483702172#file-script__aws__ec2__lib-bb-L36) 2) Building the request myself with a fork of aws-api https://github.com/AdGoji/aws-api/blob/master/dev/examples.clj#L112 3) Waiting for someone else to do this and keep things running via the JVM until that point https://github.com/cognitect-labs/aws-api/issues/120 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

jeroenvandijk09:06:19

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

borkdude09:06:25

maybe there could be a pod-babashka-aws

jeroenvandijk09:06:37

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)

jeroenvandijk09:06:40

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

borkdude09:06:03

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

borkdude09:06:21

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

borkdude09:06:57

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

jeroenvandijk09:06:21

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

jeroenvandijk09:06:28

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

jeroenvandijk09:06:01

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

borkdude09:06:49

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

borkdude09:06:03

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

borkdude09:06:47

or socket REPL

jeroenvandijk09:06:09

Ah that's cool so in theory an approach like this could work with babashka https://github.com/jeroenvandijk/clojure-scripting

borkdude09:06:53

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

borkdude09:06:20

Here's an example of how to talk to an nREPL: https://github.com/borkdude/babashka#bencode

jeroenvandijk09:06:12

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

borkdude09:06:25

clojure.lang.ExceptionInfo: Unable to resolve classname: java.net.ConnectException

borkdude09:06:31

could add 😉

borkdude09:06:58

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

borkdude09:06:18

Added the class on master. Feel free to experiment 😉

jeroenvandijk10:06:39

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

borkdude10:06:22

Why not use clojure in that case?

jeroenvandijk10:06:04

Because it could be a persistent jvm process in the background

borkdude10:06:14

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

jeroenvandijk10:06:39

I would like to use Clojure and this seems doable

jeroenvandijk10:06:18

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

borkdude10:06:53

Maybe start as pod-adgoji-aws or something

borkdude10:06:06

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

jeroenvandijk10:06:51

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

bhurlow12:06:36

@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