-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make profiles resolve recursively? #19
Comments
Thanks. Could you elaborate on your use-case a little further? How exactly are you splitting up your configuration, and why? |
The one I had is a datomic-connection component that is used by a kafka-streams component that is used by the app. The datomic-connection configuration has to be provided by the app as during development I would use datomic-peer and in production I would use datomic cloud which we would switch via profiles. Some more reasons doing this style were that we have several micro services of this manner and config files were getting really huge so it was a good way to split things up in a hierarchical manner. The app is something like this; App repositoryBoth files have the config for :datomic/connection
config.edn
Kafka streams lib repositorystream-processor.edn
|
While this isn't a general solution, if you're just choosing the values of a single key, then you could write: {:datomic/connection #duct/include "datomic-connection.edn"
:kafka-stream-component/stream {:datomic-conneciton #ig/ref :datomic/connection}} And then in {:uri "datomic://..."} Or whatever configuration you want. |
I found this issue while looking for a similar solution, so let me explain my use case: I wanted to include migrations in a separate config file, both the I was thinking maybe I could create a |
There needs to be more documentation on this, I agree! If you take a look at your current configuration, you'll see that there are three profiles:
So what do you do if you want to create your own profile? Just inherit from the one whose behavior you want in your {[:foo.profile/migrations :duct.profile/base] #duct/include "foo/migrations"
...} If you want your config file to be less cluttered, you can move the inheritance to {:foo.profile/migrations [:duct.profile/base]} And then in your {:foo.profile/migrations #duct/include "foo/migrations"
...} |
Thank you very much, that's perfect!! Thanks for a great library, by the way. |
Old behavior of
:duct.core/include
keyconfig foo.edn
config bar.edn
config.edn that includes bar.edn
And prep'ing config.edn would result in
Trying something similar with
#duct/include
#duct/include
assumes the expanded config map will be under a profile key, so simple replacing:duct.core/include
with#duct/include
will not do.e.g.
config foo.edn
config bar.edn
config.edn that includes bar.edn
does not recursively resolve.
Some more contexts from slack convo
The text was updated successfully, but these errors were encountered: