Katamari is an effort to remediate some limitations I’ve encountered using Leiningen for large multi-project repositories AKA monorepos by leveraging
clojure.tools.deps(.alpha) and attempting to follow deps example of decomposing a particular part of the build process by trying to solve the general problem of maintaining (and detecting changes in) a graph of build rules as discussed in Build systems ala carte (youtube video).
While the core concerns of resolving dependencies and maintaining a build graph decompose out well, the need to generally detect, introspect and act on change makes developing build systems (and tasks which want to consume change information) a challenge.
To this end Katamari consists of a user facing “client/server” layer which aim to make it easier to write tools with good CLI UX by amortizing JVM startup, the
roll system which implements building and an API by which to define build products almost entirely independently of the server layer, and some supporting libraries like
maxwell which makes it easier to write change-aware programs by implementing datastructures that track and can somewhat explain how they were modified.
At present, Katamari is under fairly active development but has reached a state where the core concepts are somewhat stable and I’m comfortable starting to show them off.