This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-26
Channels
- # aleph (5)
- # announcements (16)
- # babashka (36)
- # beginners (161)
- # calva (24)
- # cider (8)
- # circleci (45)
- # clj-kondo (5)
- # cljs-dev (25)
- # cljsrn (5)
- # clojure (116)
- # clojure-europe (10)
- # clojure-nl (18)
- # clojure-uk (14)
- # clojuredesign-podcast (6)
- # clojurescript (50)
- # cursive (12)
- # data-science (8)
- # datomic (8)
- # duct (39)
- # emacs (6)
- # fulcro (21)
- # graalvm (12)
- # kaocha (17)
- # off-topic (184)
- # pathom (1)
- # pedestal (2)
- # re-frame (31)
- # reagent (24)
- # reitit (1)
- # sci (1)
- # shadow-cljs (23)
- # sql (147)
- # tools-deps (8)
- # vrac (3)
- # xtdb (35)
@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
(someone else could also be my future self :))
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
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
Ah that's cool so in theory an approach like this could work with babashka https://github.com/jeroenvandijk/clojure-scripting
Here's an example of how to talk to an nREPL: https://github.com/borkdude/babashka#bencode
Looking at my own script 😅 prepl is not that different https://github.com/jeroenvandijk/clojure-scripting/blob/master/client/src/clojure/scripting/client.clj
Not sure if all classes are available in babashka, but other than that nothing too special I think
apart from that, the code at least loads: $ lein bb /tmp/client.clj.txt #'clojure.scripting.client/-main
Haha nice
😎 cool
I think a pod-babashka-aws
backed by a JVM prepl could be useful
Because it could be a persistent jvm process in the background
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
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