:deps manifest dependencies do not respect :mvn/repos in dependent project

Question

Problem

It's impossible to depend on a deps.edn-based project using git or local dependency when that project uses custom maven repos. Attempts to build classpath for projects depending on such projects will fail.

Repro

I created a minimal repo that illustrates the issue: https://github.com/vlaaad/deps-mvn-repos-repro

It contains 3 deps.edn projects: lib, app-local and app-git.

lib contains a single deps.edn file that defines a custom maven repo and a dependency that pulls from that repo.

app-local contains a single deps.edn file that defines a :local/root dependency on lib.

app-git contains a single deps.edn file that defines a :git/url dependency on lib.

Expected behavior

Running clj -P should succeed in lib, app-local and app-git projects.

Actual behavior

Running clj -P succeeds only in lib and fails in app-local and app-git with the error "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

My understanding is that this is by design, for security, so you don't depend on some project and have it randomly hijack where dependencies are being pulled in from: you should be able to control which repositories all your dependencies are coming from.

If something you depend on, in turn depends on something coming from a non-standard repo, it's up to you to decide whether that is safe and if so, add that repo explicitly to your own deps.edn in the appropriate order.

That's my read of it. I'll be interested to hear the official answer.

Comments

That's about right with where we are on it right now but it could change.

Same conceptual issue with: https://clojure.atlassian.net/browse/TDEPS-46

---

Surely I wouldn't want that maven repo to override my dependencies, but pulling those that don't exist in central/clojars would be welcome...

---

Security is a great reason to not do this automatically. One low-risk place that tooling could help though is walk the tree of dependencies and give a list of maven repos that they are attempting to add and maybe which dep is attempting to do so.

---

Maybe this could be an option for each individual dep, since there are some legitimate use cases where you want it.

I'll give you a concrete example:

In Metabase we have our Amazon Redshift extension as a separate `:local/root` subproject; Amazon has its own repo for the Redshift JDBC driver. Ideally we'd just have the custom `:mvn/repos` in the subproject and be able to pull that into the main project whenever we include it. As it is right now we have to copy the repo path and specify `:mvn/repos` in two places.

Something like

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

would work I think