如何使用deps.edn在多个项目间共享公共依赖/工具？

Question

以下是我的一般问题陈述（这也适用于monorepo）

1. 一个开发团队协作工作在多个项目上，每个项目都有自己的deps.edn文件，
2. 那些开发者在自己的~/.clojure/deps.edn文件中配置了自己的首选工具，
3. 团队作为一个整体想在多个项目中以某种程度的一致性提供一个标准化的别名和一些“锁定”版本（例如，:override-deps或:default-deps），以处理关于某些库或工具版本的版本一致性问题。

第1点和第2点由CLI/t.d.a.支持，但没有地方可以放置多项目标准化的一部分。

目前，希望实现第3点的人在使用CLJ_CONFIG提供团队标准的deps.edn文件时，可能会丧失第1点。这被认为是一种微妙的做法（尽管CLJ_CONFIG 有文档说明）。

Michiel Borkent指出，他的clj-kondo工具在读取配置数据的来源方面遇到了类似的问题，他的解决方案是提供一个命令行参数，可以指定多个要读取的配置文件。Clojure CLI可以采用类似的方法，允许合并任意数量的deps.edn文件（在系统+用户级别的文件之后以及在命令行-Sdeps数据之前）。

当前的“系统+用户+项目+命令行”逻辑已经集成到tools.deps.alpha中自身，因此这不仅仅是一个CLI脚本更改——要解决此问题采用的方法需要对所有要在基于用户特定别名的结合deps.edn环境下运行的工具可用（如这里所讨论的https://ask.clojure.org/index.php/9848/tooling-based-tools-alpha-construct-basis-specified-aliases）。

Comments

过去几年几乎没有更新。我们能做些什么来推进这个项目吗？

Answer 1

哎呀，我已经提交了这个跟踪此问题的jira，但是忘了在这里添加链接：[https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-174](https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-174)

Comments

此链接会导致重定向到整个问题列表，看起来这就是URL

https://clojure.atlassian.net/browse/TDEPS-174

---

是的，jira的URL/ UI是最糟糕的...

Answer 2

我关于这个问题有一个后续问题。对于“共享”的部分——是共享一整套依赖还是一套依赖版本（类似于 Maven/lein 依赖管理）很重要？

在后一种情况下，指定版本不会包括依赖，如在 deps.edn 中的 :deps - 需要由项目包含，但可以只有一个空协调项，由默认值填充版本。

Comments

我们主要的用途是 :override-deps，这样我们就可以“锁定”系统下所有子项目中某些依赖的版本（非 :default-deps）。对于工具等共享依赖是次要的，但绝对是锦上添花。

我们的共享工具是测试依赖项、测试运行器和 uberjar 构建。

---

如果在你的依赖中不指定版本，版本锁定似乎可以是 :default-deps？这两者不同之处在于 :default-deps 不会添加到实际的依赖中，只是当需要时提供版本，而 :override-deps 将做到这两点。

---

:override-deps 会在出现位置覆盖传递依赖的版本（这是我们想要的），但如果那些库没有被其他方式请求则不会添加到依赖中。

":default-deps"只为具有空版本的明确依赖项提供版本（正确吗？）。

---

正确，抱歉。我混淆了:deps和:override-deps（晚上回复晚晚的风险：）。

Answer 3

需要共享的东西只有别名吗？

还是也包括依赖项？如果是后者，那它们仅指外部依赖项，还是也包括共享项目集中的本地依赖项？

Comments

我们有一些共享的别名以及依赖项。我会私下与你分享我们的"共享依赖项"文件，这样你可以确切地知道我们在做什么。