Affect lein deps :tree

[mfikes]

It would be nice if lein deps :tree were updated to show some of the stuff that you can get from clojure -Stree, in particular if you have a git dep, the former won't show it, but the latter will.

[RickMoynihan]

That would be nice, but it might be a bridge too far, mainly because I'm not sure it'd be worth the effort of making it work.

What is your usecase, given that you can already do clojure -Stree and lein deps :tree?

[mfikes]

Perhaps one interesting use case would be a fairly complex project with several profiles (and ultimately potentially different aliases in them). I don't know if this is possible, but something like

lein with-profile :dev deps :tree

might help, as a convenience, in sorting out what dependencies are being pulled in via that profile's lein-tools-deps configuration.

[mfikes]

I suppose a bigger problem here is that git deps and :local/root deps, aren't really "deps" as far as lein is concerned. (They are really just extra directories on the classpath.) Perhaps that mismatch would make it really hard to do anything about.

[RickMoynihan]

Hey @mfikes

Yes my feeling was the same.

I think before we look at this we really need to understand exactly what semantics we're shooting for, i.e. whether deps are 100% from deps.edn, or whether they include deps merged from leiningen profiles/plugins etc too.

I think at the moment we replace the whole :dependencies vector, so it's 100% from deps.edn, but that's assuming plugins etc aren't getting a chance to inject themselvesand other profiles etc.

If we're aiming for a hytbird model where some deps can be included from leiningen then I can see why such a tool would be useful for debugging.

Personally I'd rather avoid the hybrid model, though it might be partly outside of our control, and I'm not entirely sure it's not possible for this to happen yet.

If deps are 100% from deps.edn then we can probably build a custom tool to let you print -Stree from whatever profile you're in, by using the tools.deps API; though I'm not sure it's a high priority given you can probably just use clj -Stree and aliases to achieve the desired effect.

[mfikes]

A related aspect: If you do lein deps :tree, the dependencies are shown as a flat list, as opposed to a tree. A consequence is that if lein is used to build and deploy a project using lein-tools-deps, then the resulting pom.xml lists all of the deps instead of only listing the top-level deps.

Perhaps a consequence of this is that it would affect consumers of such a JAR, producing a different maven dependency resolution, affecting exclusions, etc.

[RickMoynihan]

Haha, yes well spotted! 👀

This is currently expected behaviour, due to the way we do things; though I must confess I hadn't thought about the case of downstream deps.

In one sense I like our current approach which is that assuming you're building an application (i.e. there's noone else downstream of you) I think it will guarantee resolution is identical to what tools.deps does; as all tools.deps will have resolved the dependencies first, and then we lift and flatten them as siblings to the top of the tree. i.e. our tree has a uniform depth of 1. Though I should probably check this assumption with someone more knowledgeable i.e. AlexMiller etc.

In the case of using a library though, yes, this approach may lead to different override behaviour because our transitive deps have been lifted closer to the root of the tree.

I vaguelly remember AlexMiller talking about how tools.deps resolved things slightly differently to maven/leiningen, with regards to prioritising conflicting dependencies; but I can't recall the details... and could well be wrong about that.

If resolution is the same then we can just export the direct dependencies, if they're different then perhaps we want different modes of resolution e.g. :application and :library?

[favila]

Flattening deps is a problem for me. I was using lein-tools-deps to build library jars for deps-managed projects, and flattening really messes up the deps tree and makes exclusions and managed-deps useless.

Unfortunately I don't know any library-jar packaging and deployment solution for deps.edn. lein-tools-deps came the closest (use lein just for the lein build and deploy to a private repo). Everything else is concerned with application jars or uberjars. What the heck do people use?

[favila]

This thought occurred to me. I don't know how lein internals so I'm not sure if this is implementable, but I think what I want in effect is for all deps (the flattened full list) to be added to lein's :managed-dependencies and only the roots (those mentioned in the deps.edn file, including exclusions) added to lein's :dependencies vector. That way the pom will show the actual roots, but the versions of all dependencies will match exactly what deps determined.

[RickMoynihan]

@favila: only just noticed your comment here about using :managed-dependencies and :dependencies as a way to prevent flattening the tree. I think that's a great idea, and I think you might be right that it would correctly preserve the tree, and guarantee that we use the same resolution strategy as tools.deps.

I've created a new issue #91 to track this.