Fork me on GitHub

I find duct modules half-open. They give you defaults and behaviours - transitively, courtesy of an Integrant method pulled in by the module itself - but still require you to know the internals if you want a different set of settings, or if you want to know what the defaults even are. If I am required to look under the hood of a module to find out what it is doing and what configuration settings it is setting, and how to override them, I may as well do all of that myself. Which is what I did. Where you may possibly get quite a bit of mileage of duct is by rolling your own modules because your company is making an investment into Clojure services. So you write your modules, and possibly even invest the time in reading the internals of standard duct modules out there in the wild, and assemble a leiningen template with all these modules in it, and it all works. This still leaves you with what I personally consider rather awkward requirement of doing all of your interactive development in the dev namespace. With Integrant the problem mostly goes away, and since quite a few duct modules have an explicit dependency on a library providing an Integrant key which they are configuring you can then simply depend on that instead and be explicit about the configuration the method requires.


@asier I'm watching the video, it seems to be exactly the type of information I'm looking for. Thank you!

👍 4

This feature of Duct (coming soon) will be interesting:


@michael.e.loughlin I wrote up a long post yesterday that Slack dropped apparently. The gist of it was I consider duct modules half-open, and therefore not great as encapsulated units of functionality and configuration. Where this makes sense to use is when you make this the architectural basis for your team(s) and you actually take the time to read through the sources of third party duct modules, and intend to write plenty more modules yourself. Then assuming it's all rock-solid the only major annoyance is duct forcing you to do all your interactive development in the dev namespace. Or you peel this back and simply rely on third-party integrant method dependencies, and write the config yourself, which gives you a system that is a lot more flexible.