Fork me on GitHub
#mount
<
2016-02-23
>
audaxion01:02:24

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

tolitius01:02:48

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

audaxion01:02:04

it’s a luminus project

audaxion01:02:33

i have my user ns call http/start

audaxion01:02:48

which calls my init function

audaxion01:02:58

which calls mount/start

tolitius01:02:06

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?

audaxion01:02:53

that sounds right

tolitius01:02:19

does your namespace B require a namespace A?

tolitius01:02:39

that would be the reason

tolitius01:02:30

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"

tolitius01:02:57

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

audaxion02:02:24

yeah that seems to have solved it

audaxion02:02:42

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

tolitius02:02:18

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

tolitius06:02:37

(changes are in 0.1.10-SNAPSHOT)

arnout08:02:08

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

taylor.sando13:02:32

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

tolitius13:02:37

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

tolitius13:02:43

@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 .... :)

arnout13:02:31

@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)

arnout13:02:09

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

tolitius14:02:43

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

tolitius14:02:23

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

tolitius14:02:31

boot does not suffer this problem simple_smile

arnout18:02:36

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

tolitius19:02:36

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