I think this could be fun for #adventofcode as well: visualizing puzzle solutions in clerk

How would you suggest to package it, if we’re not so keen on having the extra .bb s in clerk’s own repo. Own repo with a this bb config as the default? https://github.com/nextjournal/clerk/blob/b6bd4c402b6ff831ca8d54f1b4d3e7d9e9bef5e1/bb-runtime.edn#L1-L24

What are the reasons not to check those files into clerk? Then bb users could just use the normal clerk coordinates?

And you can reuse some of the tests as well

cc @U5H74UNSF 🙂

I guess we can work in reducing the diff. ... maybe I don’t even need an extra bb config?

Libraries don’t have their own bb config, they are always deps.edn based

Bb.edn is only for local project configuration

@U9EQP1K0X how to package it is clear, @U04V15CAJ what I’m unsure about if I’m ready to take on that extra runtime complexity at this point inside of clerk. Maybe having a branch or fork that’s updated periodically is also fine for now and doesn’t require me keeping the bb version up to date with every commit

makes sense. How would you share tasks? Or is the bb folder in the release? I’m confused at times, sorry

@U9EQP1K0X there’s no need to package the bb edn, we can just have a branch or fork that folks can use with bb, using deps edn and nothing else. This will contain the .bb files and then it just works.

ok, this is clear...

Having forks and branches leads to staleness. Why not merge it?

Btw I’m fine with whatever choice you make

So, I see the bb.edn has the same source and deps directories as the deps.edn, right? So you can just refer to that in bb.edn as {:deps {current/project {:local/root "."}}}. There is no need for a separate bb.edn to expose it as a library (that doesn't even work that way).

You could also call this project clerk-lite and rename .bb to .clj so it can be used from Clojure as well. Just some ideas ;)

> Having forks and branches leads to staleness. Why not merge it? Yes, but I think I prefer a slate Blerk over a decreased dev velocity of JVM Clojure Clerk while there's still quite a few open design questions, one Clerk settles down that's different

and on the question of clerk-lite I'm curious of how lite it really has to be, might be easier to just implement the whole enchilada rather than talk describe the differences from normal clerk. Speaking of which, iirc nippy does run somehow, was this by ways of https://github.com/justone/brisk#babashka-pod-support?

this was meant as a first experiment, to probe if it's possible, what the limitations are, and if there's interest from users in this existing…

the first question is a yes, the second we're still figuring out and I haven't heard much on the third question, yet

I guess pandoc doesn't even need to be a pod, it's just about distributing the binary to users and shelling out to it…

so could ask folks to install pandoc on their own

that's also an option

or is there good ways to distribute a binary using maven?

no, pods have their own distribution mechanism which works seamlessly. https://github.com/babashka/pod-registry

ah so that's a thing that pods solve

currently there is ongoing work to have "pods as library" so you can use deps.edn to get the newest version of a pod but this is in progress

does a pod only distribute the needed architecture then?

I see https://github.com/babashka/pod-registry/blob/master/manifests/com.github.clojure-lsp/clojure-lsp/2022.02.01-20.02.32/manifest.edn

re "that's also a thing pods solve", yes. clj-kondo also has a pod while you can also install it yourself, but when using it as a pod, it's installed for you. e.g. quickdoc uses clj-kondo but you won't notice this, it's automatic

nice, so even if it's just a single binary, looks like a pod might make sense

is there also stateless pods?

> does a pod only distribute the needed architecture then? yes, only the architecture you need is pulled

a pod is as stateless as your library that is exposed is. but the idea is that it's started only once so you can run functions from it without paying the startup time each time

ok, so for the padoc pod there would not need to be another process running unless I'm just in the process of parsing a file

the pod runs for the duration of your program: it is started only once, used many times

if pods is only used as a binary delivery mechanmism, is it also possible to write a pod that doesn't "run"?

> if pods is only used as a binary delivery mechanmism It's not intended as "only a binary delivery mechanism", it's intended to provide functionality to bb from other platforms that bb can't run from source. You can view these are libraries that run in another process.

When you load a library in Clojure, you don't normally unload that library after using that library. Similar to pods: they define namespaces in your environment, you don't remove these namespaces.

You can conditionally load pods if you don't want the process if you're not using it, if that is a concern

my concern is having another process running that might not get cleaned up properly, and in the case of a pandoc pod wouldn't provide any value since the main process can also just shell out

I hear @U9EQP1K0X has markdown in quickjs working. Does bb expose some of the new interop from Project panama already?

has anybody ever created a pod using https://justine.lol/cosmopolitan/?

@U04V15CAJ this is a pass at using quickjs: https://github.com/nextjournal/clerk/pull/232/commits/995e2645487ba76c86175b1559526cf16e736a63 it’s a bit of a hack. I need to copy our es module from resources (inside the jar) to a local file in order for quickjs to be able to import it with relative paths. Or would you have a better idea around that?

Fun approach :) No, I don't think there is a way around this, unless you use clerk as a git dep, then all files are available on disk

also the string escaping is pretty so-la-la

@U9EQP1K0X you could maybe slurp the markdown resource and feed it as an -e expression to quickjs as well, to make the string escaping even worse :-D

I tried, had some troubles with the size of the module

you could also spit everything out to a temp folder and run qjs from there

right, and that just once at bb init?

you could also create a fallback for nodejs (which is more commonly installed)

> right, and that just once at bb init? yeah, or only when necessary

true

much nicer