Clojurians Log v2

@sgerguri > … and the developer is meant to stay in the dev namespace, which means that they either need to develop in said namespace or pull things into it, which can be cumbersome. It’s a little more verbose than mount for sure, but this isn’t really a problem. You just: ((integrant.repl.state/system :component.you/want) some test args) Or add a rich comment block:

(comment
  (def mycomp (integrant.repl.state/system :component.you/want))
)

Or add :injections [(require '[integrant.repl.state :as igrepl])] to your :repl profile. And access anywhere via a shortcut igrep/system Or more commonly (in my workflow) I set a scope-capture (sc.api/spy) and then jump into the captured scope with sc.nrepl.repl/in-ep at which point your REPL will have all lexically bound symbols bound to whatever they were passed.

Personally I find integrant is significantly better than mount. mount complecting components with vars is cute at first; but it forces everything into a singleton by default. With mount you can’t easily have multiple systems running in the same REPL for instance. Integrant is simple not easy - but can be made easy with some workflow/habit tweaks.

Thanks @rickmoynihan - that's helpful. I don't think we'll ever have a use case for having multiple system instances (beyond parallelising test runs, which we likely won't need either), but I appreciate the writeup!

@sgerguri: Well it depends on your workflow; but if you like to be REPL driven it’s a godsend. You can have one dev system stored in integrant.repl.state/system and then run your test suite from your REPL too without them interfering with each other. I think a lot of people only ever run tests through lein test (or equivalent); but then you lose the ability to debug tests from the REPL, and things like your IDE’s stack trace tooling (jump to stack frame etc).

Also duct lets you for example fire up multiple configurations of a system. One thing I’d like to do is refactor our config so I can start up all our active customer configurations in a single system, with each customer running on a different port (browser tab). Then checking visual regressions etc becomes so much easier, and each code change is effectively then live updated into each customer in dev. So it can enable a faster feedback loop.