deps 清单依赖项不尊重依赖项目中 :mvn/repos

Question

问题

当项目使用自定义 Maven 存储库时，无法使用基于 deps.edn 的项目依赖于 git 或本地依赖项。尝试为依赖于此类项目的项目构建类路径将失败。

重现

我创建了一个最小化存储库来演示该问题：https://github.com/vlaaad/deps-mvn-repos-repro

它包含 3 个 deps.edn 项目：lib、app-local 和 app-git。

lib 包含一个单份 deps.edn 文件，它定义了一个自定义 Maven 存储库和从该存储库拉取的依赖项。

app-local 包含一个单份 deps.edn 文件，它定义了一个对 lib 的 :local/root 依赖项。

app-git 包含一个单份 deps.edn 文件，它定义了一个对 lib 的 :git/url 依赖项。

期望行为

在 lib、app-local 和 app-git 项目中运行 clj -P 应该成功。

实际行为

在 lib 中运行 clj -P 成功，但在 app-local 和 app-git 中失败，并出现错误“Error building classpath. Could not find artifact net.sf.saxon:saxon-dom:jar:9.1.0.8 in central (https://repo1.maven.org/maven2/)”。

Answer 1

我的理解是，这是出于安全考虑而有意为之，这样你就不会因为依赖某些项目而被随机劫持，而这些依赖可能来自某个未知位置：你应该能够控制所有依赖来自哪个存储库。

如果你依赖的东西反过来又依赖于来自非标准存储库的东西，那么决定是否安全就轮到你了，如果是安全的，那么请按适当的顺序明确将那个存储库添加到你的 own deps.edn 文件中。

这就是我的理解。我很想听听官方的回答。

Comments

现在这个情况就是这样，但可能会有所变化。

和https://clojure.atlassian.net/browse/TDEPS-46所示，存在相同的概念问题。

---

当然，我不想那个 Maven 仓库覆盖我的依赖，但如果能够拉取那些在 central/clojars 中不存在的依赖，那将是受欢迎的...

---

安全是自动执行此操作的绝佳理由。但是，工具可以帮助的低风险领域可能包括遍历依赖项树，并提供一个正在尝试添加的 maven 仓库列表以及可能是试图这样做的依赖项。

---

也许这可以为每个单个依赖项提供一个选项，因为在一些合情合理的用例中你可能需要这个选项。

我来举一个具体的例子

在Metabase中，我们将Amazon Redshift扩展作为一个独立的`:local/root`子项目；Amazon有自己存放Redshift JDBC驱动的仓库。理想情况下，我们只是在子项目中添加自定义的`:mvn/repos`，并在需要时将其集成到主项目中。目前的情况是，我们必须复制仓库路径并在两个地方指定`:mvn/repos`。

例如

```
{:extra-deps}
 {metabase/redshift {:local/root "modules/drivers/redshift", :mvn/include-repos true}}
```

应该可以工作