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

Question

问题

当依赖的 Git 或本地依赖项的项目使用自定义 Maven 仓库时，无法使用基于 deps.edn 的项目进行依赖。尝试为依赖于此类项目的工程构建类路径会失败。

重现

我创建了一个演示问题的最小仓库： https://github.com/vlaaad/deps-mvn-repos-repro

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

lib 包含一个定义自定义 Maven 仓库和从此仓库检索依赖项的单一 deps.edn 文件。

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

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

预期行为

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

实际行为

在 lib 中运行 clj -P 成功，但在 app-local 和 app-git 中运行失败，错误为：“构建类路径时出错。无法在 central（https://repo1.maven.org/maven2/）中找到 artifact net.sf.saxon:saxon-dom:jar:9.1.0.8”

Answer 1

我的理解是，这是按照设计来做的，为了保证安全，你不应该依赖某个项目，而这个项目又可能在任何随机的地方劫持依赖项的拉取：你应该能够控制所有依赖项的存储库来源。

如果你依赖的某个库反过来又依赖非标准存储库中的东西，那么这个是否安全就由你来决定了；如果是的话，你可以在自己的 deps.edn 中明确添加那个存储库，并按照合适的顺序排列。

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

Comments

我们目前就是这个情况，但可能会改变。

这个观点与： https://clojure.atlassian.net/browse/TDEPS-46 draw some similarities

---

我当然不希望这个 Maven 存储库在我的依赖上覆盖，但如果能拉取中央/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}}}
```

这样的配置应该是可行的