This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-14
Channels
- # announcements (3)
- # babashka-sci-dev (22)
- # beginners (6)
- # calva (36)
- # cljsrn (1)
- # clojure (59)
- # clojure-europe (31)
- # clojure-france (3)
- # clojure-gamedev (1)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojure-uk (4)
- # clojurescript (6)
- # conjure (1)
- # cursive (11)
- # data-oriented-programming (1)
- # datahike (2)
- # docker (8)
- # duct (4)
- # emacs (1)
- # figwheel-main (5)
- # kaocha (1)
- # leiningen (8)
- # lsp (64)
- # malli (10)
- # membrane (5)
- # nrepl (11)
- # off-topic (5)
- # portal (6)
- # quil (9)
- # reagent (62)
- # reitit (15)
- # releases (3)
- # ring-swagger (2)
- # shadow-cljs (36)
- # specter (2)
- # tools-deps (21)
@borkdude When you have a moment, I wanted to see if this all sounds reasonable to you for the "read & cache pod namespaces on installation" concept:
1. For each pod declared in bb.edn
:
a. Download and install it if necessary
b. Look for pre-existing namespaces-cache.edn
file in cache dir and load it if found
c. If no cache file found, run pod, send :describe
op, load returned namespaces, write out cache file, & shut down pod
d. Make the first usage of any of the pod's vars start it back up and leave it running like it does now on (load-pod ...)
assuming that all sounds reasonable, can you give me a pointer to the load-fn
where you thinking it would make sense to wire up the "we're using this pod's namespace, so start it up" logic?
ok so perhaps after looking for built-in namespaces, we look in common/ctx
in a new :pods-namespaces
key or similar for a closure that starts up the pod?
yes, when the namespace doesn't exist as a normal dependency, we look into the cached namespaces of each of the pods in bb.edn
I think I understand the concepts now, so I'll try coding it up. thanks!
we could extract the namespaces into a separate file so we have describe.edn
and namespaces.edn
, the latter can just be a flat list we look into
or we could even store it as some more optimal format, but this is an optimization, I think .edn will be fast enough for this right now
yeah that seems right
so we only really need to cache the namespaces, but we could just cache the entire describe response, you never know what it will be good for right?
yeah makes sense