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

Question

以下是我的一般问题声明（这适用于 monorepo）

1. a 开发团队协同工作于多个项目，每个项目都有自己的 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

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

还是也包括依赖？如果是后者，这些依赖是否仅限于外部依赖，或者它们也包括了共享项目的本地依赖集？

Comments

我们有某些别名和依赖是共享的。我会私有地与你分享我们的“共享依赖文件”，这样你可以看到我们具体在做什么。