This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-14
Channels
- # asami (1)
- # babashka (50)
- # beginners (70)
- # bristol-clojurians (6)
- # calva (36)
- # chlorine-clover (1)
- # cider (4)
- # clj-kondo (3)
- # cljdoc (49)
- # cljsrn (5)
- # clojure (96)
- # clojure-australia (3)
- # clojure-dev (1)
- # clojure-europe (84)
- # clojure-nl (4)
- # clojure-spec (9)
- # clojure-uk (65)
- # clojurescript (31)
- # community-development (6)
- # conjure (17)
- # cursive (8)
- # datascript (5)
- # datomic (12)
- # duct (3)
- # emacs (18)
- # figwheel-main (2)
- # fulcro (7)
- # helix (1)
- # jobs (3)
- # luminus (7)
- # off-topic (77)
- # pathom (3)
- # portal (1)
- # rdf (4)
- # re-frame (1)
- # reitit (4)
- # remote-jobs (4)
- # reveal (15)
- # rum (1)
- # sci (38)
- # shadow-cljs (22)
- # spacemacs (1)
- # specter (6)
- # sql (1)
- # test-check (1)
- # tools-deps (60)
- # vim (12)
@bdrillard: No you can’t do that.
Because the meta-merge of profiles is done before the ig/ref
dependency resolution.
The semantics of :some/component #ig/ref :another/component
are that the instantiated :another/component
becomes the sole config value for :some/component
, not that the configuration for :another/component
should be given to :some/component
.
Typically you’d just do this by doing
{:duct.profie/base {:some/component {:base :config}}
:duct.profie/dev {:some/component {:extra :dev-config}}
Depending on your exact use case though you can do other things, for example where you want to share common config across multiple components you can do things like define a :duct/const
component for the common config, and then have each component that uses it do (mm/meta-merge (:defaults opts) opts )
in the body of their ig/init-key
.@rickmoynihan, do you have suggestions in the scenario where you don't have control over the consuming ig/init-key
s implementation?
In my usecase, I've written some Integrant methods around the Testcontainers library, and I want :duct.database.sql/hikaricp
to consume some of the info that's emitted by my Testcontainer init-key
(e.g. host, port, database name). And then there's also just some default config common to all my Hikaricp connections (adapter, transaction isolation, etc). But I don't have control over the :duct.database.sql/hikaricp
init-key implementation to apply a pattern for it to destructure some base & extra config.
@bdrillard Well in that case you could probably do something with a duct module to do it