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

Question

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

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

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构建。

---

看起来在 deps 中不指定版本时，固定版本似乎是 :default-deps？这两者在 :default-deps 不向实际依赖添加任何内容，仅提供所需的版本，而 :override-deps 则会两者都做。

---

:override-deps 在需要的地方覆盖了传递性依赖的版本（这正是我们想要的）但如果没有其他请求，就不会添加这些库到依赖中。

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

---

是的，对不起。我混淆了 :deps 和 :override-deps（夜间回复迟的后果：）。

Answer 3

需要共享的内容只有别名吗？

还是也包括依赖？如果是后者，它们是否只针对外部依赖，或者是包括共享项目集中的本地依赖？

Comments

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