Fork me on GitHub

Possibly stupid question. What's the difference between a pod and a "babashka lib" (Babashka dependency that can be used in bb.edn :deps or with deps/add-deps)? Example with pods and libs: --- Trying to answer it myself. > pod: a program that exposes namespaces with vars via the pod protocol. [< > |source>} I'm lead to believe: 1. A babashka lib can run in a normal babashka process, and is compatible with the babashka interpreter 2. A pod exposes a Clojure API - but under the hood, it can run in a different process, for example in JVM or on Node 3. The motivation to use a pod is to be able to "package and pull in" crucial functionality from a different platform Am I on the right track?


You probably already know this, but one difference is that libs ship with Babashka itself and don't have to be included in :deps.

👍 1

thats pretty much it. some more reasoning is that a pod is used for things that are more "native" too. ie things that are available better as native compiled things like sqlite. bb doesnt have a proper native interface yet and pods are a way to use that too.

👍 1

also the pod protocol is more of a remote procedure call than a clojure api so as to enable use in arbitrary languages. its similar to the nREPL protocol

👍 1

In case anyone wants to write AWS Lambda functions using Babashka, I've created a cheeky little custom runtime: I'll add nicer ways of deploying the runtime and functions using the runtime, but for now, you can use it in the AWS console or the AWS CLI. 🙂

🎉 2
🙏 1
🚀 2
Karol Wójcik16:06:25

Cool! Yet it lacks pod + deps caching


It lacks everything so far. 😂


If you can explain what you mean by these things, I’d be happy to have a go at implementing them.


I cleaned up the tasks a bit so you can now easily deploy the runtime:

[jmglov@laurana:~/Documents/code/clojure/blambda]$ bb deploy
Decompressing .work/babashka-0.8.156-linux-aarch64-static.tar.gz to .work
Adding file bootstrap
Adding file bootstrap.clj
Compressing custom runtime layer: /home/jmglov/Documents/code/clojure/blambda/target/
Publishing layer version for layer blambda
Published layer arn:aws:lambda:eu-west-1:289341159200:layer:blambda:7

❤️ 1
👍 1

It works with Graviton2 lambdas! 🎉

👍 2

It would have been great to use aws cli profiles with bb deploy as a parameter. eg bb deploy dev-profile The aws profiles are defined in .aws/config file, they allow you to assume a role. Currently, the deploy task is using the default profile which is not always usable


You can set the AWS_PROFILE env var to achieve this. Feel free to open an issue in Github and I can add it to Blambda as a glad to bb deploy as well.


@karol.wojcik @dennisa @jmglov @grzm and others, I'm starting an AWS wiki page here: Feel free to add anything, reorder, add blog posts, whatever you can find about bb + aws.

👍 3
Karol Wójcik17:06:09

Hmm, I would add that all the existing layers for AWS Lambda (except HL) I saw don't support deps & pods caching. It narrows possible use cases of Babashka on AWS Lambda.


It's a wiki, go ahead :)


Howdy ! I've been experimenting with bb today (I know! I waited too long) and it's awesome


So many things Just Work[TM] - on day 1 it's already so much easier than bash once a conditional or loop is involved

🏆 1

Fantastic work @borkdude and everyone else!

❤️ 2

I'm going to post a few things I was happily surprised by here (let me know if I should contain my enthusiasm better :-))


For one thing, I love how Java is at your fingertips. I was able to use LinkedBlockingQueue without a hitch to implement a simple filesystem watcher


That's a great example. If you want something more off the shelves, you can also use the fswatcher pod:


Pretty cool! Does that bundle a native dependency?


yes, the native dependency is written in golang


Nice. I'm trying to keep it simple for now and relying on an external process works well for that


Sure, makes sense


Then of course I love how easy the code reads. This is a "test && commit || revert" script a la Kent Beck, and that's exactly what the code says


I see you are writing a Node thing. There's also #nbb if you're interested in doing that part in Clojure :)


Haha yeah I'm using node only as an example for now


Interesting pattern, thanks for sharing this


It's a different style of working which forces you to take tiny little baby steps


I usually do this manually, dozens of "wip" commits to a branch


The hardcore thing is if the tests fail it does an automatic git reset --hard


A little bit too hardcode for me probably ;)


So you need to start over from the last point where the tests passed


Yeah, it'd kind of like a step further from TDD


but the syntax is slightly different:

(shell { optional opts here} "ls -la" "other" "args")


aha so that's something I wanted to ask you about


I had shell here first but then I was like, wait a minute, that's asking for trouble


passing a string that's tokenized by splitting on space makes it easy to go (str "git add " myfilename)


which of course is buggy if myfilename contains a space


hm. but what you're saying is that you can pass those extra args as positional params?


it supports more arguments:

(shell {} "git add" "my-filename" )


and if you want to write it as a single string, it supports:

"git add 'my filename'"


that last one I wouldn't do, no need to do shell escaping in a real programming language


this style is convenient in babashka - but keep doing what you're doing then :)


but I do get the positional args.


anyway, tiny bit of feedback I have here - I didn't understand that from the docs


I tried to pass in a vector, which I knew to be safe


and it confused me that process takes a vector whereas shell takes positional args, plus extra args that are tokenized


the shell function actually comes from babashka tasks, and like the clojure function, it takes position args, so you can write:

(apply clojure "-M:foobar" *command-line-args*)


only the first argument is tokenized, the extra args are not


right, maybe that could be clearer in the docs


ok, thanks, I'll improve that


I also added sh?! btw, on the following assumption: In bash you shell out in two ways: • When using set -e execution stops upon non-zero exit status (this should always be the default, as it is with bb's shell) • Without -e you can check the exit status yourself


IMO these are the two main ways to invoke a subprocess in a shell context


(There's also the var=$(date) use case)


So I found it convenient to have a shortcut for that

👍 1

Anyway, bb's process handling is already better than Python (which is the main contender in my view)

🎉 1