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

Question

问题

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

复现

我创建了一个说明该问题的最小仓库：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的本地根依赖项。

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

预期行为

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

实际行为

运行clj -P只在lib中成功，在app-local和app-git中失败，并出现错误“构建类路径错误。在整个中心找不到artifact net.sf.saxon:saxon-dom:jar:9.1.0.8 (https://repo1.maven.org/maven2/)”。

Answer 1

我的理解是，这是出于安全考虑而设计的，这样您就不依赖某个项目，并可能无意中在其他地方被劫持：您应该能够控制所有依赖项来源的仓库。

如果您所依赖的项目反过来又依赖来自非标准仓库的内容，那么是否安全取决于您自己，如果安全的话，请显式地将该仓库添加到您的自己的 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}}}
```

这样的配置应该是可行的。