如何使用deps.edn在多个项目之间共享常见的依赖关系/工具？

Question

这里是我的总体问题陈述（这也适用于单一代码仓库）

1. 一个开发团队协作进行多个项目，每个项目都有自己的deps.edn文件，
2. 这些开发者在自己的~/.clojure/deps.edn文件中配置了自己的首选工具，
3. 该团队作为一个整体希望在不同项目之间保持一定程度的库或工具版本的一致性，通过提供一些标准化的别名和一些“固定”版本（例如，:override-deps或:default-deps）。

项目1和项目2的支持是通过CLI/t.d.a.，但没有地方可以挂载多项目标准化的部分。

目前，那些希望得到第三个的人正在通过使用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的依赖——它们仍然需要由项目包含，但可以只为版本使用默认值而没有坐标。

Comments

我们主要的用例是为：override-deps，这样我们就可以“锁定”我们系统中所有子项目中某些依赖的版本（不是：default-deps）。实际共享工具等的依赖次之，但绝对是一个锦上添花的点。

我们的共享工具包括测试依赖项、测试运行器和ubermeta构建。

---

如果您的deps中没有指定版本，锁定版本看起来类似于：default-deps，对吗？这两个不同之处在于：default-deps不会添加到实际依赖中，只是在需要时提供版本，而：override-deps会做这两件事。

---

：override-deps会在任何地方覆盖传递依赖的版本（这是我们想要的），但如果这些库没有被其他请求，则不会添加到依赖中。

":default-deps"只为具有空版本值的显式依赖项提供版本(对吗?)。

---

对了，对不起。我把:deps和:override-deps搞混了(晚上回复晚些时候的风险：)

Answer 3

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

还是也包含依赖?如果是后者，这只是对外部依赖，还是说它们还包含在共享项目的本地依赖集中?

Comments

我们有一些也是共享的别名以及依赖。我会私下里把我们的"共享依赖"文件分享给你，这样你就能确切地知道我们在做什么。