James Reeves

> Very much agreed, but I would like to be able to monitor the running system as well. Sure, but it seems to me that there are two ways of...

Thanks for providing an alternative approach. It goes in a different direction to where I want to take Integrant, but that's the benefit of forks and alternative designs :) It...

Sure. A lot of modules involve searching and transforming the configuration. One example is the `:duct.module/ataraxy` module. A configuration like: ```edn {:duct.core/project-ns foo :duct.module/ataraxy {["/bar/" id] [:bar id]}} ``` Will...

> I might be wrong, but it seems that you implicitly assume that there will be one instance per module type in the system. Right. Most modules currently have that...

> I think I understood your point pretty well, but I fail to see how making config transformers the "ultimate goal" helps the end users. I guess it depends on...

> It could be both, "simple" and "easy" In some cases, but frequently it's a trade-off. A flat map is simpler than a nested map. A `prep` transformation is simpler...

That seems fine in principle. I don't like the extra dependency needed for babashka's spec, but we could make spec support optional anyway by dynamically loading it in `assert-pre-init-spec`.

At least in Clojure (I'm not sure about babashka but I assume it works the same way), you can lookup vars dynamically via `find-var`: ```clojure (defn- assert-pre-init-spec [system key value]...

> Regarding `assert-pre-init-spec`, firstly if we're using find-var is it actually even necessary to do that require, as can't we rely on the namespace that defines the pre-init-spec key to...

Thank you for wanting a way of donating. The thought is very much appreciated. However, I don't think there's enough left to do on Integrant to warrant a donation box....