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

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.

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

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

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

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

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

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