Clojurians Log v2
tools-deps
Not sure if this is important/interesting but I hit what seems to be a gitmodules related problem. https://gist.github.com/olivergeorge/abc428669538622b88dd13cd876aceae happened with this deps.edn file:
{:deps {clj-statecharts {:sha "942eb942594cdd6876556cf212d59cff245fa9fe" :git/url "<https://github.com/lucywang000/clj-statecharts.git>"}}}
we have a ticket for git submodules actually https://clojure.atlassian.net/browse/TDEPS-126
have been through a few rounds on the patch, but I haven't looked at it recently
Thanks Alex
Got part 1 working of clj-kondo deps.edn linting:
when you look at a deps tree (`clj -Stree` , lein deps :tree , mvn dependency:tree ), what question are you trying to answer?
1. what are the set of deps I'm using?
2. what version of a particular dep am I using?
3. what are the transitive deps of a particular library?
4. is a particular dep version out of date?
5. is some dep I'm expecting not on my classpath?
6. why is some dep on my classpath?
I guess that might be a variation of 6, but “what deps depend on this dep?”
1 2 5 6. With the additional use case of chasing "which dependencies transitively depend on A, and need to have exclusions added." That's particularly annoying in clj as it only shows the dependency that was retained.
I’d say all of them to some extent, but mainly 5, 6 and 2…
1 is more often asked as a general high-level question; so I’d normally just look at the deps.edn to get a rough overview, and overview of the intention.
I usually use -Stree etc to help answer a slightly different question, which is “What deps are being chosen and why”. This usually being a combination of the above options. I think the distinction is often when I’m running -Stree it’s as a debugging tool, and I don’t know what the problem is yet (i.e. it could be 1 because I’ve started with the wrong aliases, it could be 2 because the wrong version of a transitive dep is being selected, it could be 3 if we’re accidentally explicitly depending on a transitive dep which has been removed or isn’t available in the alias combination. Similarly for 5 sometimes 6 if an unused dep is causing a transitive dep to be a different version).
For example all of those questions might uncover the reason behind a ClassNotFoundException, or perhaps a method being called with the wrong arguments etc. But until you run -Stree you don’t know which it’s going to be.
Ahh just seen @seancorfield said essentially the same thing in the main channel
some possible answers there, but that's an open set
You should give higher weight to the answers of others than me (I'm not using Clojure in production myself), but usually 1 3 6 and sometimes 2.
Seems like a question you could reasonably put on State of Clojure Survey 2021 if you were so inclined 🙂
so, interestingly you can't answer #3 or to some extent #6 correctly based on the result of any of those tools
in many cases deps show up at multiple places in the "tree" (really, a graph) and all print it only at one location (trivial example, clojure is usually included N times but only shows up once)
wanting other use cases or to chime in with which of the above are most useful?
just what it says above - when you reach for this, what question are you usually trying to answer?
or separately, what are some dep tree related questions you would like to be able to answer?
used it today to diagnose a bad release of piggieback. it had some extra junk tucked in the jar and the cleanest repo was to clj -Sdeps '{:deps {cider/piggieback {:mvn/version "0.5.1"}}}' -Stree. then rebuilt the jar locally and checked with clj -Sdeps '{:deps {cider/piggieback {:local/root "target/piggieback-0.5.1.jar"}}}' -Stree that the resultant jar was clean so it was just a deploy problem
Usually 1 & 3 for me
so this is really #1 in a diff scenario
yes. 1 and 3
well it doesn't really answer #3 - that's often a lie as it's thinning a graph into a tree
My two scenarios are: 1. trying to debug a problem that turns out to either be an unexpected transitive dependency or an unexpected version of one of them (which is a combination of several of those six things to one degree or another) and 2. as part of my script that attempts to determine #4 above (by synthesizing a new project from the output of clojure -Stree and then running clojure -Stree on that and seeing what versions changed -- but only because none of the "outdated deps" tools out there work properly in our monorepo setup at work).
I'd say scenario 1 is a mix of #3, #5, and #6 primarily (and I realize that the tree isn't a full/accurate representation of the actual graph, but it's "close enough" and can always be used selectively with -Sdeps to select specific top-level deps to examine further).
I don't know if this falls into 5 or 6, but I most often: what is forcing dep x to be version y?
sometimes I use it for 1, but more often that's -Spath with a grep to find a particular dep
Mostly 6 and 2 for me. 5 and 3 sometimes.