Fork me on GitHub
#babashka
<
2019-11-19
>
borkdude10:11:05

I'm considering making the conch low level namespace unaliased, but you can still require it. Instead the conch main namespace will take its place under the conch alias. Babashka and sci have gotten a lot better and now they can support the conch macros:

$ bb -o '(conch/programs ls) (ls)'
LICENSE
README.md
bb
doc
examples

jeroenvandijk11:11:41

btw, did you already think about supporting a whole range of dependencies (libraries)? I'm assuming we cannot add everything to Babashka, so it would be nice if we could somehow extend Babashka on a per case level. I'm thinking for instance about an AWS api layer

borkdude11:11:19

@jeroenvandijk That's what sci as a library is for. Babashka is once instance of what you can do with sci, but people have been using it to make other GraalVM based tools that can execute user code as well

jeroenvandijk11:11:59

Ah yeah makes sense. I was thinking though it would be nice to not be dependent on the GraalVM compilation step, and just think in terms of one binary (babashka)

borkdude11:11:19

You mean a fork of babashka for internal use?

jeroenvandijk11:11:44

No I mean babashka would be able to pull in other layers, like how clj / tools.deps can pull in dependencies. So we would basically need a native version of Clojars (I think)

jeroenvandijk11:11:04

I recently looked into AWS Lambda layers, maybe this would be the right approach

jeroenvandijk11:11:51

It is not clear to me how this should all work, but I think it would be nice to do many more things with something like Babashka

borkdude11:11:48

layers are like docker image layers? that only adds files to your environment. bb is one file. I don't see how that would work.

jeroenvandijk11:11:19

No i don't see it either yet. I'll think about it more and experiment with the idea and let you know! 🙂

borkdude11:11:55

bb could interop with other native libraries or call other native binaries by shelling out. but then you would still have to pre-compile AWS libs to native code

jeroenvandijk11:11:45

yeah that's true, but let's say there are 10 of those libraries. For most people it would mean just combining those libraries and not having to use GraalVM at all

borkdude11:11:48

I have been thinking about this, you could have like bb_aws, bb_hiccup etc. but these would be forks

jeroenvandijk11:11:42

yeah that would be an option too. I guess it's all premature now and the community around this still needs to unfold

jeroenvandijk11:11:53

I see many applications internally though

borkdude11:11:02

it's an interesting thought, but I don't know the answer to it yet either, so yeah

borkdude11:11:56

if GraalVM allows Java / Clojure libraries to compile to some kind of C library with headers, then that could potentially be used via dynamic linking

borkdude11:11:09

but I haven't explored that option

jeroenvandijk11:11:15

Yeah i understand

borkdude11:11:40

Hmm:

--shared builds a shared library

jeroenvandijk11:11:51

And I guess for most use cases of Babashka it's just about scripting, so even shelling out would be acceptable?

jeroenvandijk11:11:47

wow, if that means what i think it means, that's pretty cool

borkdude11:11:02

^ yeah, I welcome you to try it 😉

jeroenvandijk11:11:15

Yep, it's on my list now (but will take some time => holidays ahead)

borkdude11:11:15

probably not trivial

jeroenvandijk11:11:07

It is a nice direction anyway 🙂

borkdude11:11:15

@jeroenvandijk if you want you can also contribute to https://github.com/lread/clj-graal-docs/issues/15 along the way

borkdude11:11:12

if that works, we can use clojars to distribute native version of jvm libraries... and bb could use those... that would be so cool 🙂

jeroenvandijk11:11:40

like how javascript libraries are distributed via cljsjs and clojars? hmm yes smart, that would save us from writing some code and hosting a server 🙂

borkdude11:11:49

maybe small Java wrappers would be needed, since they are using these Java annotations which are cumbersome to use in Clojure, but we'll see

holyjak12:11:08

@borkdude if it is of interest to you, this is what I am trying to achieve with bb - https://github.com/holyjak/blog.jakubholy.net/blob/cryogen/content/fix-files.clj - clean files during my migration from Gatsby to CryogenWeb. Very useful!

borkdude12:11:04

I doubt if defn in bb currently supports preconditions btw.

borkdude12:11:42

I'll make an issue for that in sci.

borkdude12:11:38

it does support assert, so for now you can use that

borkdude15:11:52

$ bb -o '(conch/let-programs [clj-kondo "/usr/local/bin/clj-kondo"] (clj-kondo "--lint" "-" {:in "(inc)" :throw false}))'
<stdin>:1:1: error: clojure.core/inc is called with 0 args but expects 1
linting took 10ms, errors: 1, warnings: 0