This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-04
Channels
- # aleph (23)
- # announcements (1)
- # babashka (21)
- # beginners (70)
- # biff (3)
- # cider (8)
- # clj-kondo (45)
- # clj-yaml (9)
- # clojure (69)
- # clojure-europe (82)
- # clojure-nl (1)
- # clojure-norway (2)
- # clojurescript (34)
- # conjure (19)
- # core-typed (6)
- # cursive (2)
- # events (5)
- # fulcro (55)
- # honeysql (1)
- # integrant (18)
- # jobs (1)
- # lsp (124)
- # malli (10)
- # meander (1)
- # off-topic (26)
- # polylith (8)
- # reagent (7)
- # releases (1)
- # remote-jobs (1)
- # sci (2)
- # shadow-cljs (19)
- # squint (5)
- # vim (17)
- # xtdb (31)
Hello! Is it possible to ignore some top level keys when loading an edn file? for example im using a mix of integrant and aero and would like integrant to ignore the :common
key:
{:common #include "bob/common.edn"
:bob/storage #ref [:common :bob/storage-conn]
:entities/queue-config {:database #ig/ref :bob/storage}
:bob/queue {:url #ref [:common :bob/queue-conn :url]
:user #ref [:common :bob/queue-conn :user]
:password #ref [:common :bob/queue-conn :password]
:conf #ig/ref :entities/queue-config}}
currently i have this to ignore it
(defmethod ig/init-key
:common
[_ _])
Does that work? Do you not need to return the value (even if unmodified)?
(defmethod ig/init-key :common [_ val] val)
Since I dont use it anywhere with a #ig/ref
it works 😅 otherwise yeah it shouldn't i think
since im using it with aero to reuse conf hence its a bit clunky. the :common
is purely a map which is used only by aero
I’m doing something similar, but never realized that I was never using ig/ref to call into :secrets
(that is what mine is called that is doing the same role as your :common
)
I guess after you read it in with aero, but before passing it to integrant, you could remove :common
and any other top-level keys that integrant doesn’t need.
yeah i was thinking of that too, was thinking if theres some other/declarative way. 🙂
will go with that for now, thanks!
If you wanted it to be more ‘declarative’ (and maybe you’ve already thought of this, too) you could put some metadata on the value for :common
(and any other keys you want to discard), read it in with aero, then scan the map for values flagged with the metadata and drop them, and then pass to integrant. That puts the info of ‘I don’t want this key in integrant’ in your config.edn file, and not in code. I don’t know if aero preserves metadata (hopefully it does?).
Right, makes sense. Yeah didn't think that much 😛 Putting a dissoc
with a TODO: make more declarative
now and will try out your idea! Thanks again!
Belay that. It might not be possible to include metadata in edn files. (I just tried a quick experiment.) But it might be possible with a custom aero reader tag that can be responsible to add the metadata as the object is created, and then do the same: look for the metadata and drop those values from the map before passing to integrant.
right
Just stumbled upon the same problem. Considering a) integrant and aero both seem like commonly used tools, and b) I can't find docs or examples explaining how to make integrant deal with aero "meta-keys" such as reading secrets, I get the feeling that I'm not supposed to solve the problem this way. Did you find a decent approach to this?
My current approach (probably based off the ideas that came about from this very thread, but I can’t remember for sure) is to organize my config.edn file into groups based on namespaced keywords. That is, my config map has keys like :config/secrets
, :config/datomic-client
, :config/postgres-spec
, etc. And it has other keys like :services/datomic
, :services/adapter
, etc. Then I have these functions to load it:
(ns acme.config
(:require [aero.core :as aero]
[integrant.core :as ig]))
(defmethod aero/reader 'ig/ref [_ _ value]
(ig/ref value))
(defn get-profile []
(or (keyword (System/getProperty "profile")) :dev))
(defn config
"Read `config.edn` from classpath using :profile from JVM sys prop."
[profile]
(aero/read-config (io/resource "config.edn") {:profile profile}))
(defn services []
(into {} (remove #(= "config" (namespace (key %)))) (config (get-profile))))
;;; ------
(ns acme.main
(:require [acme.config :as config]
[integrant.core :as ig]))
(defn -main [& _]
(ig/init (config/services)))
;;; ------
(ns user
(:require [integrant.repl :refer [go halt reset]]
[acme.config :as config]))
(integrant.repl/set-prep! config/services)
(comment
(go)
(halt)
(reset) ;; NOTE: mapped in VSCode/Calva to ctrl_alt_space r
)
Basically, before passing the config map to ig/init
or set-prep!
I strip out any entries where the key has namespace ‘config’. Then I don’t have to provide init-key
and halt-key!
methods for all of them. It’s also nice because my services are passed around all over in my app, but the original secrets are gone and can’t be accidentally leaked.I see, thanks for the thorough reply! I ended up dissocing the undesired keys prior to passing it to integrant as well, like in this example and the thread. It gives me somewhat of an itch though, that you are able to combine the integrant configuration and aero configuration in a single file by introducing the ig/ref reader, but that integrant stumbles when encountering some of the basic syntax of aero, like #include. I'll run with this for a while, but might revert to separating the integrant and aero configs. Thanks again!