Clojurians Log v2

@arnout i've just noticed your mount-lite 2.0. do you have a public example app showcasing or i can only look at the test suite?

Hi @onetom, I don't have an example app, but the tests should indeed suffice

And otherwise, just ask 🙂

thanks, i will give it a try. im just a bit worried how will it cooperate with boot-jetty, boot-refresh and the boot repl and running tests from cursive... 😕

What kind of problems do you expect?

for example when clojure.tools.namespace.repl/refresh unloads changed namespaces, the states defined in them wont be stopped

i saw in the 0.2.0 docs that > States are not automatically stopped anymore on redefinition. however as i understand refresh is not doing redefinition

True, stopping states is your own responsibility, especially with tools.namespace. With tests, it's quite easy to add a fixture that ensures all states are stopped after your tests have run (regardless of their results).

With tools.namespace it is possible to add metadata to the namespaces in order to have different refresh behaviour.

for tests i would just use separate sessions anyway probably since with cursive they are supposed to be run in the same repl as the dev process

But this is more suitable if you'd use mount-lite 0.9.x or the original mount.

im gonna try it soon, but i suspect this boot task won't cut it: https://github.com/samestep/boot-refresh/blob/master/src/samestep/boot_refresh.clj

according to https://github.com/clojure/tools.namespace i should do something like this:

(defn start []
  (alter-var-root #'my-app (constantly (start-my-app))))

(defn restart []
  (stop-my-app my-app)
  (refresh :after 'dev/start))

so i guess it should replace the middle of the boot refresh task with (mount/stop) (refresh :after 'mount.lite/start)

hmm... but that would reboot the whole app 😕 that's not good

From the former 0.9.x version docs: > This cascading is great to work with, and in combination with the tools.namespace library it can really shine. Whenever you make sure your namespaces with defstate definitions have {:clojure.tools.namespace.repl/unload false} as metadata, calling (clojure.tools.namespace.repl/refresh :after 'mount.lite/start) will only stop the required states (in correct order) and restart them.

so this still applies to 0.2.0? i haven't seen this in those docs.

No, it does not, because in 0.2.0 states do not stop themselves when being reloaded.

ok, thanks, i will play with it and report back with actual examples if something doesn't work

but it sounds like it make sense to mark all defstates with unload false, no?

All namespaces (with defstates) you mean?

oh, i misread it... so the namespaces should be marked with unload, not the defstates...

nevermind, i will come back with more specific questions soon. thanks in advance!

Correct, if you use 0.9.x. Otherwise, you are responsible for stoping the states beforehand.

That would be great, see ya.

but ctnr/refresh doesn't seem to have a hook for that... =:-/ i dont want to use 0.9.x; im strictly talking about 0.2.0 because i want independent states for tests within the same repl. i don't see any other way how to make a convenient workflow in cursive otherwise.

@arnout do i see well that by default i can't define explicit dependencies between states, only by using mount.extensions.explicit-deps/start? i was wondering how can i put multiple defstates into one namespace.

for example if i do

(ns app.datomic
  (:require
    [app.conf :refer [opts]]
...
(defstate uri
  :start (:uri @opts))

(defstate conn
  :start (do (println "Connecting to Datomic...")
             (connect @uri))
...

clojure.lang.ExceptionInfo: state uri not started
    name: "uri"
clojure.lang.ExceptionInfo: error while starting state #'app.datomic/conn
    var: #'app.datomic/conn

which practically suggests that i should have 1 defstate per namespace, unless they are not dependent on each other.

on https://github.com/aroemers/mount-lite you said > The order in which the states are started is determined by their load order by the Clojure compiler. which i understand it refers to the order of namespaces, but it would make sense to start the states in definition order? or it's actually not a realistic use-case, hence better not add more code to support it?

i thought the problem is solved by adding :dependencies [#'uri] to the conn state as i saw it in the mount.lite test suite, but after removing it, the problem is gone 😕

@onetom, indeed, by default the dependencies between the defstates are inferred by the Clojure compiler. So yes, the defstate are started in definition order. Also, you are free to put as many defstates in one namespaces as you want, whether you use the explicit-deps extension or not.

How are you starting your system, that yields you the error you mention?

Hi @jorisbontje, long time no see 🙂