This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-13
Channels
- # announcements (2)
- # aws (4)
- # babashka (14)
- # beginners (186)
- # cljdoc (2)
- # cljsrn (7)
- # clojure (56)
- # clojure-austin (1)
- # clojure-australia (2)
- # clojure-europe (46)
- # clojure-france (5)
- # clojure-nl (16)
- # clojure-norway (7)
- # clojure-spec (76)
- # clojure-sweden (15)
- # clojure-uk (13)
- # clojurescript (60)
- # code-reviews (2)
- # conjure (8)
- # datascript (1)
- # datomic (4)
- # depstar (10)
- # emacs (9)
- # events (4)
- # exercism (1)
- # fulcro (36)
- # graalvm (8)
- # introduce-yourself (3)
- # jobs-discuss (2)
- # kaocha (14)
- # lsp (1)
- # minecraft (8)
- # new-channels (1)
- # off-topic (3)
- # pathom (6)
- # polylith (9)
- # re-frame (48)
- # shadow-cljs (5)
- # specter (26)
- # tools-deps (19)
- # vim (2)
- # vscode (1)
@seancorfield Did you ever find a satisfactory solution to managed-deps with tools deps? re: https://ask.clojure.org/index.php/9849/teams-common-dependencies-tooling-across-multiple-projects
@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?
so each sub-project has a deps.template.edn
which we then use to generate a corresponding deps.edn
comments, etc you store in the template, the generate deps.edn are a bunch of sorted maps, to be more friendly with git etc
I've hooked this script in the :init
phase of bb.edn so any time we execute a task, the deps.edns are synced
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.