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

Question

以下是我的一般问题陈述（这也适用于单代管仓库）

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

第一条和第二条功能通过CLI/t.d.a.得到支持，但找不到多个项目标准化片段的挂载点。

目前，希望实现第三条的人正在使用CLJ_CONFIG来提供一个团队标准的deps.edn文件，但在这个过程中丢失了第一条。这被认为是一种折衷方案（尽管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

Comments

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

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

---

是的，jira的url / ui是最差的...

Answer 2

关于这个问题，我想继续提问。对于“共享”的内容——这是共享一组依赖还是一组依赖版本（类似 Maven/Lein 的依赖管理）的重要事情？

在后者的情况下，指定版本不会包含依赖，就像在 deps.edn 中的:deps一样——它们仍然需要由项目包含，但可以有 nil 的坐标和填充默认值的版本。

Comments

我们的主要用例是用于 :override-deps，这样我们就可以“锁定”子项目中所有子项目的一定依赖的版本（不是 :default-deps）。真正共享的工具等依赖次之，但这确实是一个受欢迎的特性。

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

---

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

---

:override-deps覆盖了出现在（我们需要的位置的）转置依赖的版本，但如果这些库没有其他请求，则不会添加到依赖中。

:default-deps只为具有 nil 版本显式依赖提供版本（对吗？）。

---

抱歉，刚才混淆了 :deps 和 :override-deps（深夜回复时的风险）。

Answer 3

需要共享的内容是否仅限于别名？

还是包括依赖项（deps）？如果是后者，这些依赖项是否仅限于外部依赖项，还是也包括共享项目中的本地依赖项？

Comments

我们有一些既共享为别名又共享为依赖项。我将私下与你分享我们的“共享依赖项文件”，以便你可以确切地了解我们在做什么。