: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的: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

我的理解是，这是出于安全设计的考虑，这样你就不依赖某些项目，它不会随机地劫持依赖项的来源位置：你应该能够控制所有依赖项来自哪些仓库。

如果你依赖的东西反过来依赖于非标准仓库中的某个东西，那么你是否觉得这是安全的，如果认为安全，那么请显式地将其仓库添加到自己的deps.edn中，并按照适当的顺序进行。

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

Comments

这与我们目前的情况相符，但可能会有所变化。

与此相似的概念性问题与https://clojure.atlassian.net/browse/TDEPS-46

---

我当然不希望那个Apache Maven仓库覆盖我的依赖，但 pulling那些在中央/clojars中不存在的仓库会受欢迎...

---

出于安全原因，应该不自动这么做。然而，工具可以帮助逐步检查依赖项树，并列出他们试图添加的maven仓库以及可能的企图添加该依赖项的依赖项。

---

可能可以将此作为每个依赖项的选项，因为有一些合法的使用场景你想这么做。

我将给你一个具体的例子

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

如下所示

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

我想这应该可以工作