如何使用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 构建。

---

如果你在依赖中未指定版本，锁定版本似乎是`:default-deps`？两者不同在于`:default deps`不会添加任何依赖，只提供所需版本，而`:override-deps`将两者都会进行。

---

`:override-deps`会覆盖传递依赖中的版本（无论它们出现在哪里），这就是我们想要的（但不添加依赖，除非这些库被其他方式请求）。

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

---

对了，对不起。我混淆了：deps和：override-deps（晚上太晚回复的风险：）。

Answer 3

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

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

Comments

我们有一些别名和deps共享。我会私人间共享我们的“共享deps”文件，让您可以看到我们正在做什么。