Fork me on GitHub

@grzm there are various solutions to this, Sean has written a couple of blogs about their mono-repo setup using polylith. At my current job we are using a straightforward approach using babashka and templates that we use to generate deps.edns in all sub-projects from common data / versions.


Yeah, I've been following his mono-repo articles: good stuff, but I'm not convinced polylith is the answer for our team. I've been considering the templates/generation method as well.


At least you get a "what you see (generate) is what you get" effect which is easy to follow and debug


Agreed. The drawback is of course caching by another name: are the generated files up to date?


I'll share our script


so each sub-project has a deps.template.edn which we then use to generate a corresponding deps.edn

👍 2

comments, etc you store in the template, the generate deps.edn are a bunch of sorted maps, to be more friendly with git etc


Nice. Thanks!


I've hooked this script in the :init phase of bb.edn so any time we execute a task, the deps.edns are synced


We might have someone on our team using babashka. 😉

🎉 2

you can also hook it to a commit hook, cd etc

👍 2

Polylith supports :override-deps now but we haven't felt the need for it yet, but it "solves" that issue I'd raised about sharing common deps -- and, to be honest, after I'd had some long, in-depth discussions with Alex about it, shifting everything to essentially a :dev alias in the top-level repo deps.edn file addressed pretty much all my concerns anyway.


It's still a bit frustrating that :local/root deps can go "stale" -- but we're mostly working with just one .cpcache folder now (at the top of the repo) so -Sforce or just blowing away the folder isn't too much of a burden.


So, to answer your Q from the channel @grzm, where we are now is a "satisfactory solution to managed-deps", yes.


Thanks for the follow-up, @seancorfield


At this point, we have about a quarter of our codebase migrated to Polylith (in 30+ "bricks" and nearly 20 "projects"), so we have :dev (and :test) aliases in the project deps.edn for Polylith and :everything / :runner aliases for the non-migrated code, and we use :local/root deps for all our subprojects/"bricks". Plus we have a good-sized build.clj file from which we run all our tests and build uberjars etc.