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.

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

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?

not sure what you mean

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

@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.

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)

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

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.build|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).

Take a look at how depstar does it: https://github.com/seancorfield/depstar/blob/develop/src/hf/depstar/uberjar.clj#L314-L333

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)

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.

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

re "I'm asking whether there is a way to know the local url of each procured artifact per dep", see https://clojure.github.io/tools.deps.alpha/clojure.tools.deps.alpha-api.html#clojure.tools.deps.alpha/lib-location

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)