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

Question

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

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

此链接将重定向到整个问题列表，看起来这是一个链接

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-dependencies不会添加到实际的依赖中，只是提供版本（如果需要的话），而：override-dependencies将执行两者。

---

：override-dependencies在需要的地方覆盖了依赖项的版本（这正是我们想要的），但如果这些库未被其他请求，则不会将它们添加到依赖中。

：default-dependencies只为显式依赖提供版本（对吗？）

---

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

Answer 3

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

还是也包含 dependencies？如果是的话，是只包括外部 dependencies，还是也包括共享项目集中的本地 dependencies？

Comments

我们有一些既是别名也共享的 aliases。我会私封地与你分享我们的 "shared deps" 文件，以便你可以看到我们正在做什么。