如何使用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脚本更改，解决这个问题所采取的方法需要对所有需要基于用户特定别名运行分析的工具可用（如此处所讨论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 中——它们仍然需要由项目包含，但可以用默认值填充的 nil 坐标来完成。

Comments

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

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

---

尽管如此，如果你没有指定版本，这看起来就像是 :default-deps？它们之间的区别在于 :default 版本不会添加实际的依赖，只是提供所需的版本，而 :override-deps 则会两者都做。

---

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

:default-deps 仅为具有 nil 版本的全局依赖提供版本（不是吗？）

---

对，抱歉。我混淆了：deps 和：override-deps（晚上回复晚会出错的危险：）。

Answer 3

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

或者也包括 deps？如果是后者，那它们仅对外部依赖进行操作，还是包括在共享项目中的本地依赖？

Comments

我们有一些共享的别名和 dep。我会私下与你分享我们的 "共享 dep" 文件，这样你可以看到我们具体在做什么。