Clojurians Log v2
clojure
Question regarding prior art. Has anyone done any work in the space of parameterized edn templates? I'm thinking of something along the lines of how the aero configuration library works. Some potential use cases:
• Centralizing dependency versions in a multi project repository.
• Generating configuration from a template but with slight variations based on environment.
I'm slightly hesitant to go down this road because I'd like the result to play nicely with deps.edn files but I'm not sure the best way forward to "filling" the template before handing it off to deps. Maybe keeping a deps.template.edn in the repo and fill it when clj or clojure is called?
It gets way more complicated though because there are a ton of different deps.edn files for all the subprojects. So I think the deps.template.edn idea falls on its face.
Check out https://bigconfig.it/. It combines functionality from Selmer, deps-new, and Integrant. While its primary use case is operations, I’ve found it really useful for managing my dotfiles as well.
re: "a la carte" overrides + other deps, yes, it is very easy for individual subprojects to add to or override the default deps - their local deps files will take priority over the common one
re: "multiple groups of shared deps" - it's hard to say for sure. you might be able to package those under aliases in the deps.edn file for the centralized versions subproject.
but then that means needing to remember which aliases to enable "by default" for the subprojects, which is a bit cumbersome
I think I can get away with a single aggregator if I keep it slightly under specified so it only contains the most core deps. There might be a tiny bit of redundancy across services but that's fine.
Centralizing dependency versions in a multi project repository.If you use a monorepo, you may not need templating for this. You can just have a thin versions project in the monorepo that basically defines the "canonical" set of deps, and have all your other monorepo libraries declare it in their respective deps.edn files. Has doing something like that proved insufficient for your use case?
That's an interesting thought. Basically an aggregator project for all the "common" deps and let the uncommon ones live in their respective projects a la carte?
Wouldn't you need multiple aggregators if you had multiple groups of shared deps?