Clojurians Log v2

@viesti has joined the channel

👋

Hello 😄

Good to see you guys 🙂 Let me know whether there is something we can do in holy-lambda to improve it 🙂

Thought that I missed the channel, but not with that many days 😄

@ekoontz has joined the channel

Neat to see the effort, been thinking that JVM/Clojure support in Lambda is a good thing and I like the JVM/Runtime -> native-image progression

I guess there could be progression levels, from babashka to jvm runtime to native-image even, but yeah

Actually making a babashka runtime would be fairly easy on holy-lambda side.

Maybe that's something that could potentially bring more people into the project

Does babashka supports namespaces?

Ok let me know whether I understand it correctly, but it seems that all I would have to do is to provide babashka pod

Wondering if babashka supports defmacro though

0% bb
Babashka v0.3.5 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.

user=> (defmacro foo [x] 1)
#'user/foo
user=> (foo 42)
1

Wonderful

I want to keep functionality parity between runtimes.

babashka supports namespaces also, I think all in all a lot of Clojure things, but there are exceptions, like deftype , since that is low level facility to generate a class

in #babashka, aired out an idea: https://clojurians.slack.com/archives/CLX41ASCS/p1618467130175000?thread_ts=1618416923.161500&cid=CLX41ASCS

holy-lambda has that polling loop also, to support the custom runtime

so I guess the thing would be that if the interface that holy-lambda provides for writing code against, is supported via babashka too

You can make an issue on the repository 🙂 Would love to support babashka as well 🙂

ah, true 🙂

I will implement it probably on weekend since I'm working student 😞

a babashka lambda could be packaged with docker container format even, like that example by Lukaz https://clojurians.slack.com/archives/CLX41ASCS/p1618416923161500

Ahh. Does aws lambda supports custom docker images now? I'm not aware of it

ah and forgot that https://github.com/dainiusjocas/babashka-lambda that you linked in the docs too

yeah, haven't tried out what limits there are, but Lambda supports OCI images now: https://docs.aws.amazon.com/lambda/latest/dg/images-create.html > AWS provides a set of open-source https://docs.aws.amazon.com/lambda/latest/dg/runtimes-images.html#runtimes-images-lp that you can use to create your container image. These base images include a https://docs.aws.amazon.com/lambda/latest/dg/runtimes-images.html#runtimes-api-client to manage the interaction between Lambda and your function code.

On holy-lambda side things are very simple. All I have to do is babashka-pod. Entrypoint is the same 🙂

not sure about pod actually

Meh. Not interested in packaging lambda in docker image. Zip is better imho. 😄

This is exactly what I'm doing: https://github.com/dainiusjocas/babashka-lambda/blob/master/src/lambda/core.clj

babashka pod is a subprocess that babashka can run. I think the ideas is to package stuff that can't be run with the babashka interpreter into a pod, and then use it. Allows to keep the babashka binary itself small, and extend it via the pod subprocess

This will generate the format consumable via babashka: https://github.com/FieryCod/holy-lambda/blob/master/src/fierycod/holy_lambda/native_runtime.clj#L93

hmm, right

That's wonderful approach. That way I can package babashka-holy-lambda pod as an aws layer. Zip will include just a source code for a project

hum, was also thinking that could entrypoint generate something that bb interpreter could run directly? :)

thinking https://book.babashka.org/#_reader_conditionals

thing then is that bb code might not be able to run all that java code runs, but one might be able to branch with reader conditionals

thinking that if there's reader conditional over say, bb aws pod, then you could load the java library in jvm/graal, and the pod in bb code (https://github.com/babashka/pod-babashka-aws)

but haven't looked at holy-lambda "interface" that much yet 🙂

vomiting ideas here a bit 🙂

Entrypoint generates a main function which is automatically called in bootstrap-native. The thing holy-lambda should provide is just a pod. Of course if it's possible to pack defmacro in a pod, which I now doubt.

👍 on asking on bb channel, there's good set of brains there 🙂

I guess I was thinking that could it be possible, that the whole code that is written with the holy-lambda "interface", could be runnable via bb

in which case, I guess the lambda would start by calling bb with that piece of code, which would then run the polling loop etc

if I understood it correctly that you meant to provide babashka itself as a pod, might have gotten it wrong 🙂

I mean that holy-lambda is so simple that if I provide holy-lambda pod then all the boostrap-native will do is:

bb some-file-which-defines-entrypoint.clj

yeah, exactly 🙂

what would be in the holy-lambda pod?

Hmm.. Wait...

Maybe we can do this without making another repository. Maybe I can just use those reader_conditionals.

@viesti is metosin interested in providing babashka pod?

hmm so babashka calls pods, not the other way around 🙂

I mean jsonista pod

😄

bb includes cheshire already

I can pack holy-lambda with jsonista into native image, but I would rather not.

haven't tried if jsonista runs with bb actually

but probably ~same classes used from jackson

Jsonista has to be registered in a pod. https://github.com/babashka/pod-registry

might miss some classes

aa

didn't know 🙂

much stuff happening in and around metosin, don't know all the things 🙂

ah, misread

jsonista not registered as pod

should not be needed as a pod

if you have time to provide PR for jsonista reflection hints, it's all good 😉

I will put it clear. Pod is just a library compiled with native-image which in main provides some additional functionality. I can do the following: Create fierycod.holy-lambda.pod and expose all the necessary vars for babashka runtime. Register it as a pod, but jsonista is then compiled with holy-lambda.

Babashka can run libraries not packaged as pods?

it can run code from jars

Whaat?

it can use normal java classpath, load code from jars

So why I want to create babashka pod XD?

if the clojure code in a jar users form that generate calls to JVM that are supported by babashka, that code will run

yep

that I was wondering 🙂

XDD

why a holy-lambda pod :)

but it's all good

talking out loud, getting ideas etc 🙂

Ok I think it clicks in my mind now. I will get rid of reflections in jsonista.

thank you 🙂

thinking that could just try running that example (https://github.com/FieryCod/holy-lambda#example) with bb, and see what fails and plug in stuff to make it work with babashka 🙂

deployment will be different per each runtime though

keeping that simple will require some effort

Yep. But I will hack it somehow in makefile

have forgotten all about make but that file based dependency thing is actually neat 🙂

File based dependency?

like target/output.jar -> rule to create target/output.jar

https://github.com/FieryCod/holy-lambda/blob/master/docker/ce/Dockerfile#L7-L33, this made me wonder that had you already thought about docker image deployment for Lambda, but I guess not 🙂

It's for compiling lambda.

ah hmm

Native compiled lambda needs only scratch image AFAIK.

So something lke:

FROM scratch

COPY output .

ENTRYPOINT ['/boostrap-native']

mm yeah

@viesti Very funny. But after installing locally jsonista reflections are gone.

@viesti https://github.com/metosin/jsonista/commit/90f447aac858a18194dcd95f01ca40062f41866f You just have to deploy a new release 😄

aa, hehe, neat 🙂

faint memory there being improvements on type hints lately

but forgot

on jsonista, I'm a bit new with out release processes, but I'll ask around 🙂

another thing actually that I had in mind is tools.deps support

would have to have step to AOT compile

Feel free to create an issue 🙂

set the channel description: - Project - https://github.com/FieryCod/holy-lambda - Examples - https://github.com/FieryCod/holy-lambda/tree/master/examples - Docs - https://cljdoc.org/d/io.github.FieryCod/holy-lambda/CURRENT/doc/readme

@thegeez has joined the channel

@dcj has joined the channel

Question: Should we support node.js as well? 😄 Edit: I had to provide some #(:cljs) conditionals so that cljdoc would pass the build and i have realized that support for nodejs could be easily added.

Braindump Babashka layer would consist of babashka (bb), holy-lambda-babashka (jar) (still need to patch jsonista functions though), clojure 1.10.0 (jar) User will have the layer referenced via ARN. Deployment artifact will consist of plain sources packed in .jar. This way we will keep deploy artifacts super small. No clojure, no babashka just sources (like in php 😂).