Fork me on GitHub

Is there anything like danielz/system but for mount? I guess just a set of ready made defstates?


Hey guys, I have a service which has so called 'modes'. The running mode is given by command line args. now each mode should start a certain subset of the states of the service. I used only to tell mount which states to run in each mode, but I suspect that this confuses mount about when computing the order in which the states should be started. I am I right in my assumption that proper starting order can only be done when start is called without args?


...mmm or this is just me testing with lein run without lein clean and messing with compiling order?


@colliderwriter I have not spec'ed mount yet, but if anybody else has any samples you are welcome to share


@didibus Are you looking for something specific (i.e. how to start / stop a specific resource)? Any mount specific contributions to danielz/system are very welcome. One of the reasons "pre cooked" states are not there is because mount states usually have "no ceremony" compare to component and other state managing libs. The focus is mostly on actual functions within the resources: i.e. connect / disconnect, bind / unbind, etc.. vs. writing ceremony code around these functions


@ido > proper starting order can only be done when start is called without args no exactly. the order is determined as defstates get compiled. In your case it seems you'd like to build states based on the runtime args before a call to (mount/start).


@ido for example

(defn select-mode [{:keys [mode]}]
  (case mode
    :one (mount/only #{#'foo/a
    :two (mount/only #{#'foo/c
    :three (mount/only #{#'foo/a

(defn -main [& args]
  (->> (parse-args args)
       (apply mount/start)))


@didibus Work on mount systems has been started some time ago:


@arnout Ah, that's cool to know. I'll keep an eye out for it.


@tolitius I agree that mount states are pretty lightweight, but sometimes some state requires a lot of construction and destruction code within the start and stop. So for commonly used states like the components in system, it can save you a bit of time.


@didibus yep, agree. would be good to have more contributions to danielz/system


If I've got some spare time, might contribute to that branch