This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-30
Channels
- # announcements (31)
- # aws (17)
- # babashka (26)
- # babashka-sci-dev (8)
- # beginners (16)
- # biff (1)
- # calva (9)
- # cider (5)
- # clj-kondo (3)
- # clj-on-windows (38)
- # cljdoc (2)
- # cljs-dev (9)
- # cljsrn (6)
- # clojure (58)
- # clojure-europe (47)
- # clojure-nl (3)
- # clojure-norway (21)
- # clojure-uk (2)
- # clojurescript (25)
- # conjure (2)
- # data-science (7)
- # datomic (3)
- # emacs (12)
- # events (5)
- # fulcro (5)
- # honeysql (10)
- # introduce-yourself (7)
- # lsp (4)
- # meander (3)
- # nbb (18)
- # off-topic (28)
- # rdf (1)
- # releases (2)
- # sci (5)
- # shadow-cljs (23)
- # sql (5)
- # test-check (3)
@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.
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