Clojurians Log v2

I wonder if it might be worth planning out such an endeavour first, and soliciting feedback; before filling in all the contents. In particular the arrangement of the various chapters/topics, and their order; and roughly what would be covered in each section.

I actually started that a while ago, though weavejester didn't have time to review it at the time. And I didn't pick it up afterwards https://gist.github.com/kwrooijen/fa52c9f9fa1c582e06321f3198db7397

5 months ago, time flies

But I agree, it would be nice to plan this out (regardless of what I just linked)

@kevin.van.rooijen: That seems like a pretty good outline to me, and is essentially exactly what I was thinking. In particular I think duct needs to start with an introduction to integrant, and how it’s used.

Completely agree with your last point, Duct only clicked once I realized I should be reading integrant docs / source haha. Which in heinsight seems so obvious

@kevin.van.rooijen: The main thing I’d probably de-emphasise in that is the role of the lein template. Also I’d personally be tempted to emphasise the separation between “duct as a module system”, and “duct*“, the web-framework assembled of that module system (with a lein template).

Why de-emphasise the lein template? Currently lein is an essential part of Duct

It’s not essential, it’s just assumed. Our duct app uses tools.deps exclusively. If I could change one thing about duct in the large it would perhaps be to rename the project that houses the web framework as something else, and let duct refer to the module system alone. I think this would go a long way to clearing up misconceptions; i.e. the web framework is really just the tooling (e.g. project template) and components/modules wrapping ring.

Interesting, how do you create a release then? Since the lein plugin aggregates all the duct_hierarchy.edn files ?

Yeah, that is the only thing you need to do, to decouple yourself from lein. So, the first thing is to realise that lein uberjar is a flawed concept, as it destroys the classpath when flattening the jars. Hence all you need to do is to preserve the classpath you have in dev. There are a bunch of ways you could choose to do that. We currently use pack.alpha to arrange a “skinny app”, which is essentially just <project-name>.jar lib/, where lib contains all the dependency jars, and <project-name>.jar contains the apps src and any resources we want to bundle.

Then essentially zip that into a single artifact and extract at deployment.

I see, I'll definitely take a look at that. I've been wanting to build a Duct app without Lein but this was my main roadblock

Thanks for the tip

You basically don’t need to aggregate duct_hierarchy.edn files at all. Also not doing so, gives you a lot more power; as you can essentially do stuff like that for any file. For example we take advantage of a similar mechanism for some other manifest type files we have, where the resources are meta-merged on load at runtime. In particular we use this to allow validation suites etc to be discovered/composed automatically etc… we also have libraries of fixture/reference data that can automatically be included into multiple apps by simply adding a dependency etc.

plus it makes prod and dev a lot more similar.

Since the duct_hierarchy.edn files are still in your path you don't need to merge them, right?

exactly

duct will just walk them all and meta-merge them, as it does for you in the repl.

Forgot I created an issue for this in duct, that describes the solution: https://github.com/duct-framework/duct/issues/92 Though we moved away from capsule jars, as they cause various extra headaches in prod.