James Reeves

The latest master branch should now be fixed for Travis.

The design I'm considering is something like: ```clojure (defmulti assert-key (fn [key value] key)) (defmethod assert-key :default [key value] (when-let [spec (pre-init-spec key)] (when-not (s/valid? spec value) (throw (spec-exception key...

Yep, `build` would have to be adjusted as well. My example was just a rough sketch, rather than a complete solution. I'm still undecided on various details, like whether it...

In this situation, I'd read the configuration and incorporate it into the config map before initiation. So: ```clojure (-> config (merge (aero/read-config "config.edn")) (ig/init)) ```

Can you explain why you want this? If a component depends on a promise, why not return a promise in turn? Is it that you want a way of unwinding...

I don't think adding extra arguments to `build` is a good path forward. My temptation is to write a `build-async` instead, but I'm not sure of the best way to...

`prep-key` methods should ideally be pure. Adding in environment variables should be done directly after reading in the configuration. For example, both Duct and configuration management tools like Aero have...

That functionality is planned, but unfortunately very difficult to implement. Consider a configuration like: ```edn {:duct.database/sql {:connection-uri "jdbc:sqlite:db/dev.sqlite"} :app.handler/example {:db #ig/ref :duct.database/sql}} ``` If we try to validate the spec...

I'd rather not add functionality that works for some things and doesn't work for others. Ideally a feature should have consistency. I'll give this some thought.

Originally I did call it `init-spec`, but I then realized that a `post-init-spec` method might be necessary in future. The `pre-init-spec` method is called just before the map entry is...