babashka-sci-dev

borkdude 2022-09-30T08:30:01.436359Z

@thiagokokada Someone on Twitter was referencing this: https://github.com/NixOS/nixpkgs/pull/190494

✅ 1
cap10morgan 2022-09-30T20:56:40.049839Z

I think I have a viable pod library approach that avoids the classpath scan. Just getting the details sorted out now. It relies on putting the pod-manifest.edn inside a directory (in the library JAR or local root path) that matches the munged top-level namespace element (e.g. pod-fluree-crypto.crypto -> pod_fluree_crypto/pod-manifest.edn). That way the required namespace can be mapped to a specific resource path in the classpath.

borkdude 2022-09-30T21:01:51.034839Z

how does that avoid a scan? you still need to open jar files?

borkdude 2022-09-30T21:10:42.656939Z

(this might not be a big problem, just curious)

cap10morgan 2022-09-30T21:35:47.959399Z

it loads them the say way any other :deps library gets loaded via source-for-namespace

cap10morgan 2022-09-30T21:38:59.245599Z

the extent to which that's a scan I guess depends on the loader it's passing to getResource, which I haven't looked into too much yet. but it seems to work very quickly compared to my previous classpath scanning code FWIW

borkdude 2022-09-30T21:41:40.115539Z

I think you would get similar performance for nested dirs, you don't have to use a 1 level directory for this. https://clojurians.slack.com/archives/C02FBBU61A9/p1663788790758779

borkdude 2022-09-30T21:42:52.015829Z

so next to .bb , .clj and .cljc there would be a fourth extension which contains a file that points to the pod manifest