Clojurians Log v2
tools-deps
I've developed a technique for mono-repos that I use in the Pedestal codebase. When libraries within the mono-repo depend on each other, I have a :local alias that uses :override-deps to make cross-repo dependencies local. Example: https://github.com/pedestal/pedestal/blob/master/log/deps.edn#L20 The challenge is that this use of the :local alias is not transitive, so I have to carefully reproduce these as each layer of the libraries stack up: https://github.com/pedestal/pedestal/blob/master/interceptor/deps.edn#L21 This doesn't feel like a totally rare scenario (I was just chatting internally with another mono-repo maintainer inside Nubank, sharing this trick). Ideally, there would be a way to make this transitive in some way, as in, support an additional key in the coordinates to indicate I want to activate the :local alias in the overridden dependency. Maybe something like:
{:override-deps {io.pedestal/pedestal.log {:local/root "../log" :local/alias :local}}}
polylith has some similar kind of issues, and there I believe the solution is a "dev" deps.edn that grabs everything as a local dep
so there is a single top level deps.edn that you use for dev that overrides all your monorepo deps
supporting aliases in deps is something I'm (still) considering. it seems obvious, but the consequences for dep selection are decidedly not obvious
That's what I figured. it's all edge cases, all the way down. And turtles.
another path that I'm thinking about is having more of a context (vaguely similar to maven scopes), such that you could set the context across your entire dep tree. having "test" context is the obvious Maven scope not currently supported, but something like "dev" is also interesting
there are also some other deps.edn features I'm thinking about to allow for importing/including dep modifiers from somewhere else, which is useful for managed dep scenarios or for groups of projects with shared config (like monorepos)
While you have that can of worms open, any thinking about something like managed-deps (sorry folks, this is internal to Nubank) but for deps.edn? That is, a meta-dependency that supplies the versions of other dependencies?
yes, as I mentioned in the last message
the things I mostly don't like about maven's approach are similar to the issues in oo hierarchies; a depending on rigid "inheritance" style definitions. so looking at more compositional approaches instead.
Yeah, the Polylith approach basically separates "build" dependencies out from "dev" dependencies. You use a regular workspace-level deps.edn for the REPL which has every brick (component/library/whatever) as a local dep, and then for each "project" you have a deps.edn for the actual build which can use local deps or specific maven deps as appropriate. Non-project deps.edn files, for each of the bricks, only contain 3rd party library deps, not monorepo deps.
But that does rely on the poly tool assembling "effective deps.edn" maps from all the bricks' folders...
:test deps are the "worst" part of Polylith since the tool has to merge all of those instead of being able to rely on tools.deps functionality.
I’ll second that. I often use a polylith layout, but without the tooling, which means manually maintaining a composite test path.
We do templating at work. We have an extra attribute that can be present in deps coords or aliases that tell if it should get its values (at build time) or not from a :managed-dependencies (or :managed-aliases) key present in the root deps.edn and have a small script that propagates the values to the deps files down the tree (which can be done via ci & co). A huge win is that deps.edn files are truly standalone, not complicated, what you see is what you get, you can just run a repl without having to thing about it and mess with cli flags/aliases.
it's actually oss, forgot about it: https://github.com/exoscale/deps-modules
Otherwise I would love to have something like aero #include, #merge and #ref. That would make all this much easier