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

Question

以下是我的一般问题说明（这也适用于单仓管理）

1. a 开发团队共同工作在多个项目上，每个项目都有自己的 deps.edn 文件，并且
2. 这些开发者在他们的自己的 ~/.clojure/deps.edn 文件中配置了他们自己的首选工具，并且
3. 团队希望跨多个项目保持一定的库或工具版本的一致性，通过提供一些标准化的别名和一些“锁定”版本来实现（例如，:override-deps 或 :default-deps）。

命令行界面支持1.和2.，但没有提供挂载多项目标准化片段的位置。

目前，想要3.的用户正在使用 CLJ_CONFIG 来提供团队标准的 deps.edn 文件，但在这个过程中丧失了1.。这被认为是一种有点奇怪的解决方案（尽管 CLJ_CONFIG 是有文档说明的）。

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

当前“系统+用户+项目+命令行”逻辑已被集成到 tools.deps.alpha 本身，因此这不仅是一个命令行脚本文档更改——要解决的问题需要提供可供需要根据用户特定别名执行分析的工具（如此处所述 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

Comments

此链接将重定向到所有问题的整个列表，看起来这是此URL

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

---

正确，Jira 的 URL 和 UI 确实是最差的...

Answer 2

关于这个问题，我想继续问一点。对于“共享”内容，是否需要共享 Deps 或 Deps 的版本（类似于 Maven/lein 依赖管理）？

在后一种情况下，指定版本不会包含 Deps，就像在 deps.edn 中的 :deps 一样，它们仍然需要一个项目来包含，但可以只有一个 nil 的协调者，版本由默认值填充。

Comments

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

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

---

如果不在 Deps 中指定版本，锁定版本看起来可能是 :default-deps？这两者不同之处在于，:default-deps 不会添加到实际的 Deps 中，只是在需要时提供版本，而 :override-deps 将做两件事。

---

:override-deps 会覆盖所有可传递依赖的版本（这正是我们想要的），但如果这些库没有被其他请求，它不会将它们添加到依赖项中。

:default-deps 仅仅为具有空版本的明确依赖提供版本（对吗？）。

---

对，不好意思，我弄混了 :deps 和 :override-deps（深夜回复的风险：）。

Answer 3

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

还是也包含依赖？如果是的话，这些依赖仅仅针对外部依赖，还是也包括在共享项目的本地依赖集合中？

Comments

我们有一些共享别名和依赖。我会私下分享我们的“共享依赖”文件，这样你可以看清楚我们正在做什么。