Fork me on GitHub
#duct
<
2020-10-14
>
rickmoynihan07:10:55

@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.

aeskilson15:10:18

@rickmoynihan, do you have suggestions in the scenario where you don't have control over the consuming ig/init-keys 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.

rickmoynihan16:10:54

@bdrillard Well in that case you could probably do something with a duct module to do it