@rickmoynihan I was thinking that profiles would contain partial configurations that would be optionally merged into the top-level config.

So you might have a configuration like:

{:profile/foo {:app/foo 1}
 :app/bar 2}

{:profile/foo {:app/foo 1}
 :app/foo 1
 :app/bar 2}

This would mean we could get rid of :duct.core/include, and replace it instead with a reader tag. So instead of:

{:duct.core/include "foo"}

{:profile/foo #duct/include "foo"}

A reader tag would be more flexible, because it can be used to inject configuration inside a key:

{:app/secrets {:encrypt-key #duct/include "app/encrypt-key"}}

It also pushes side-effectful behaviour out of the prep stage. The configuration and its includes are read at once, and that’s the end of the configuration I/O.

It means we can get rid of a key that’s specially treated (`:duct.core/include`)

And it means that configuration keys can be more easily grouped together.

It lends itself to some interesting functionality when combined with inheritance. For instance, we might imagine a profile key that is included by default, like :duct.profile/default. We could then use a composite key like:

{[:duct.profile/default :app/migrations] #duct/include "app/migrations"}

So this is a profile that’s always included by default.

We could redo modules in a similar way; instead of modules updating the whole configuration, they return a profile that’s merged in. I’m not sure if this would be too restrictive or not.

not sure…