如何使用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将同时进行这两项。

---

:default-deps在每个出现的位置覆盖传递性依赖的版本（这正是我们想要的），但如果这些库被重新请求，则不会添加到依赖中。

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

---

对，抱歉。我混淆了 :deps 和 :override-deps（半夜回应带来的风险：）。

Answer 3

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

还是也包括 deps？如果是后者，那么它们是否只对外部deps有效，或者是否也包括共享项目集中的本地deps？

Comments

我们有一些别名以及deps也被共享。我会私下将我们的 "shared deps" 文件与你分享，这样你就可以了解我们正在做什么。