mount

tolitius 2016-04-29T01:36:18.000180Z

@ido: it would be good to see a simple example of what you are trying to achieve. most of the time non obvious things are non obvious for a reason and there is just a different way / angle to solve the problem.

tolitius 2016-04-29T01:40:21.000181Z

explicit deps is something we were thinking about: https://github.com/tolitius/mount/issues/48 but my feeling is that a permutation of states: https://github.com/tolitius/mount#composing-states, or a lazy loaded app (in cljc mode): https://github.com/tolitius/mount/blob/master/doc/clojurescript.md#clojure-and-clojurescript-mode, or another sequence of how the app is started, will solve it.

tolitius 2016-04-29T01:40:23.000183Z

I could be wrong of course, but that would be only clear when you provide a simple example of what it is you are trying to do, and why :simple_smile:

ido 2016-04-29T21:11:11.000188Z

@arnout: your snippet above guessing how my code is right on the spot.

dm3 2016-04-29T21:31:23.000189Z

@ido so you could potentially do something like:

(ns common.kafka ...)
(defstate consumer :start (start-with-topic (topic-from (mount/args))))
(ns common.db ...)
(defstate db :start (connect-db (db-url-from (mount/args))))
(ns service1 (:require [common.kafka :refer (consumer)] [common.db :refer (db)]))
(defn do-something [] (query db) (process consumer))
basically you don't pass the states around, but rather initialize with an appropriate configuration. As an alternative you could hav e a common.config ns with a dynamic *config* var which you would bind like:
(binding [common.config/*config* (service1-config)]
   (mount/start))
I don't think passing Mount states around is supported by the design, but I might be proved wrong! :simple_smile: