Share your thoughts in the 2021 Clojure Community Survey!

Welcome! Please see the About page for a little more info on how this works.

+12 votes
in tools.deps.alpha by
retagged by

Here's my general problem statement (this applies to a monorepo as well):

  1. a development team works together on multiple projects that each have their deps.edn file, and
  2. those developers have their own preferred tooling configured in their own ~/.clojure/deps.edn file, and
  3. the team as a whole wants a level of consistency in terms of certain library or tooling versions across multiple projects, by providing some standardized aliases and some "pinned" versions (e.g., :override-deps or :default-deps).

Bullets 1. and 2. are supported by the CLI/t.d.a. but there's nowhere to hang the multi-project standardization piece.

Currently, folks who want 3. are using CLJ_CONFIG to provide a team-standard deps.edn file but losing 1. in the process. This is considered a bit of a hack (although CLJ_CONFIG is documented).

Michiel Borkent notes that his clj-kondo tool faced a similar problem in terms of where it reads configuration data from and his solution was to provide a command-line argument that specified multiple configuration files to read. A similar approach could be taken with the Clojure CLI, allowing an arbitrary number of deps.edn files to be combined (after the system + user level ones and before the command-line -Sdeps data).

The current "system + user + project + command-line" logic is baked into tools.deps.alpha itself so this is not just a CLI script change -- and whatever approach is taken to address this needs to be available to tooling that needs to run analysis based on a combined deps.edn environment under user-specific aliases (as discussed here https://ask.clojure.org/index.php/9848/tooling-based-tools-alpha-construct-basis-specified-aliases).

3 Answers

+1 vote
by
selected by
 
Best answer

Oops, I filed this jira tracking this but forgot to add the link here: https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-174

0 votes
by

I have a followup question about this. For the "shared" stuff - is this the important thing to share a set of deps or a set of dep versions (ala maven/lein dependency management)?

In the latter case, specifying the versions would not include the deps as in deps.edn :deps - they would still need to be included by a project, but could just have nil coord with version filled by the defaults.

by
Our primary use case is for :override-deps so we can "pin" versions of certain deps across all of the subprojects in our system (not :default-deps). Having actual shared deps for tooling etc is secondary but is definitely a nice-to-have.

Our shared tooling is test dependencies, test runners, and uberjar building.
by
Pinning versions seems like it could be :default-deps if you don't specify versions in your deps though? These differ in that :default deps does not add to the actual deps, just supplies versions if needed whereas :override-deps will do both.
by
:override-deps overrides versions for transitive dependencies wherever they show up (which is what we want) but does not add to the deps if those libs are not otherwise requested.

:default-deps only provides versions for explicit deps that have nil for their version (right?).
by
Right, sorry. I was confusing :deps and :override-deps (the hazard of replying late at night :).
0 votes
by

Are the things that need to be shared only aliases?

Or also deps? And if the latter, are they only to external deps or do they include local deps in the set of shared projects?

by
We have some aliases that are shared as well as deps. I'll share our "shared deps" file with you privately so you can see exactly what we're doing.
...