@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