Fork me on GitHub

What is the recommended approach to override transitive dependencies, a bit like Leiningen’s :managed-dependencies? From what I’ve seen, you cannot use :override-deps at the top level alongside :deps, it has to live under an alias, which is a bit cumbersome because people now have to remember to add the alias for all clj commands. The other option is to add the override version directly to the :deps vector but I’m not fond of that because it now looks like you project depends on it directly.


@gphilipp I would go for the last option, because in that case you are stating the truth: your app DOES depend on that specific version to function correctly


you could add a comment to it to explain why you added it


Yeah, this is what I do currently (adding an explicit comment). The other downside that I forgot to mention is that it lifts the dependency to the top of the deps tree (`clj -Stree)` and you don’t have the entry anymore under the lib that pulled that dep initially.

Alex Miller (Clojure team)14:03:54

usually I would add an :exclusions and add the dep in :deps

👍 6

I usually skip the :exclusion part due to the way tools.deps resolve dependency conflicts (usually we want the higher version). But now that I’m think of it, IIRC it doesn’t work across maven repositories or across different vendors of the same GAV, am I right?

Alex Miller (Clojure team)14:03:48

those seem like orthogonal concerns


I’ll write down a small example to clarify.


If one were to add keys to a deps maps like so:

{:extra-deps {thheller/shadow-cljs          {:mvn/version "2.11.22"
                                               :bazel/hash "hash goes here"} ; <= new map entry
1. would anything break, and 2. is there a way to resolve them along with the maven coordinates?


@jasonhlogic There’s a “procurer” mechanism built into tools.deps.alpha that could leverage that but it is not currently exposed as an extension point. @alexmiller might have more to say about that.

Alex Miller (Clojure team)21:03:12

in this particular case, you're adding keys to an existing procurer coordinate and that code may not pull them along (although generally the existing code does)

Alex Miller (Clojure team)21:03:06

if you are making your own custom procurer (some qualifier other than :mvn), it is possible to install that and have tools.deps use it and do anything you like

Alex Miller (Clojure team)21:03:30

installing custom procurer extensions is not currently possible when using the clj CLI (no one has needed it yet) but that is possible


In theory, what I would like to do is let maven do the procuring as it does now, but then to get a link to the local jar and the value of the key i have added so an external tool can hash the jar and compare for its own purposes. (the external tool, surprise, is <Https://|Bazel>). My wishcast is that some magical function would appear which 1. resolves deps 2. downloads the artifact via whatever procuring mechanism is in place 3. adds the url of the downloaded artifact to the map I added the new key to above 4. returns the new map Given that resolve-deps exists, 1 and 2 are covered, so I guess I'm asking whether there is a way to know the local url of each procured artifact per dep for reasoning purposes 🙂


The computed project basis would give you the path to the actual JAR (as well as all the rest of that data — although as Alex says I don’t think you can guarantee that your additional keys will always get passed through).


If you play with that in the REPL, you should be able to find the data you are after and verify whether your keys survive the round-trip too.


(there’s very similar code in t.d.a itself — I just knew I could find this code faster)

Alex Miller (Clojure team)22:03:46

there actually is an api method for answering this question


Fantastic. thanks very much, will investigate. Confirmed that nothing breaks when I add the extra key, so there's that.

Alex Miller (Clojure team)23:03:22

there are no future guarantees about that - you are firmly in "undefined" land

Alex Miller (Clojure team)23:03:24

re "I'm asking whether there is a way to know the local url of each procured artifact per dep", see

Alex Miller (Clojure team)23:03:19

and just fyi, Maven will also download the sha1 hash of the jar if it's in the maven repo (which it will be for things in Maven central, but not necessarily for clojars or other maven repos)