Clojurians Log v2

i’m having a problem where i have defstate defined in a file to start up my db connection, but it only starts if i explicitly load-file in my REPL

@audaxion: where do you call (mount/start)?

it’s a luminus project

i have my user ns call http/start

which calls my init function

which calls mount/start

just to clarify: you have two namespaces A and B you have your defstate defined in A in the namespace B you call (mount/start) and the database connection state does not start is that accurate?

that sounds right

does your namespace B require a namespace A?

nope

that would be the reason

ah

when you load the program, at the entry point i.e. (mount/start), namespaces need to be required in order for mount to see them. that does not mean you have to require all the namespaces with defstates since most of them would be brought in transitively (similar to how dependencies are resolved with lein / boot / maven), but something needs to tell your entry point namespace what it is "you'd like to work with"

let me know if adding a require made it work for you

yeah that seems to have solved it

looks like i need to create an issue for the luminus template

thanks @tolitius

sure, let me know if/when you have more questions

@taylor.sando, see if this resolves the issues you had: https://github.com/tolitius/mount/blob/0.1.10-SNAPSHOT/README.md#composing-states

(changes are in 0.1.10-SNAPSHOT)

@tolitius: I believe swap and swap-states are side effecting? Have you thought about naming them swap! and swap-states!?

@tolitius: The composing does work Does yurt also need to change, because I don't see a way of using blueprint

@taylor.sando thx for checking. I'll update yurt a bit later. just wanted to first make sure mount works

@arnout: I thought about it, but then I am not a "purist", and in this case thread side effects do not affect the application, and mostly affect mount internal state, which is later rolled back to its original state on (mount/stop). + most of the time these functions will be used together in composition right before the call to (mount/start).. e.g. which by itself is side effecting.. just not in the "business" context of an application + in yurt these will be detached after created, and will live locally .... :)

@tolitius: true, and they are also fine to use inside clojure.core/swap!, alter etc, as substitute! is idempotent. Still, users might be suprised if they have something like:

(def config-a
  (-> (only #'a #'b)
      (swap {#'a :some-substitute})))

(def config-b
  (-> (only #'b #'c)
      (swap-state {#'b #'d})))

(mount/start)

Maybe it is not your intention to have users use mount/your composable functions like that, but hey... users :simple_smile:

yea, for these presets I would not recommend defing them. but rather use data, which I might add later. the whole concept is not immensely useful ( my opinion :simple_smile: ), but very good to have, so I don't want to make it more complex than it needs to be. yes, there is room for error, but if you are already in a position where you splitting state configs, you'd probably know what you are doing

the only place where the data approach is really useful, might be lein profiles, since lein is declarative

boot does not suffer this problem :simple_smile:

Nice, you really gave it some thought! I hope you don't mind me spewing my thoughts here :)

@arnout: yea, I slept on it for some time.. thoughts are always welcome :simple_smile: