Fork me on GitHub
#tools-deps
<
2021-09-13
>
borkdude16:09:28

@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.

grzm16:09:53

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.

borkdude16:09:22

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

grzm16:09:33

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

borkdude16:09:04

I'll share our script

borkdude16:09:33

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

👍 2
borkdude16:09:55

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

grzm16:09:16

Nice. Thanks!

borkdude16:09:45

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

grzm16:09:46

We might have someone on our team using babashka. 😉

🎉 2
borkdude16:09:05

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

👍 2
seancorfield16:09:27

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.

seancorfield16:09:47

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.

seancorfield16:09:07

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

grzm16:09:24

Thanks for the follow-up, @seancorfield

seancorfield17:09:39

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.