@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
.https://github.com/kwrooijen/keydox/issues/1#issuecomment-708078435
Shared my thoughts. I think we're pretty much on the same page but have different approaches. I'm not sure if the "finding project name" is viable, but it would keep the keydox.edn
file simple (instead of having to add extra context / nesting)
Yeah seems like we’re very close to agreement here. I’ll repond on the issue to clarify a few more points though.
1👍@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