Fork me on GitHub
#tools-deps
<
2020-01-13
>
slipset07:01:05

I ran into a subtle problem over the weekend with clj -Spom on https://github.com/clj-commons/pomegranate. The original pom.xml has the dep for wagon-provider-api here https://github.com/clj-commons/pomegranate/blob/master/pom.xml#L101 whereas the pom.xml generated by clj -Spom with this deps.edn https://github.com/clj-commons/pomegranate/blob/master/deps.edn#L12 put the dependency declaration for wagon-provider-api earlier in the pom.xml.

slipset07:01:55

One reaction to this would of course be 🤷 , but from https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html we have that

slipset07:01:58

> Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins.

slipset07:01:16

And the kicker is that wagon-provider-api depends on an older version of plexus-util than the other deps of pomegranate, so by changing the order of the deps in the pom.xml, pomegranate broke.

slipset07:01:13

Thinking of it, I’m not sure why I’m writing this, I guess it’s just as an amusing story.

slipset10:01:13

I guess there might be a question in here: Is the order in which the deps are listed in the generated pom.xml predictable in any way?

dominicm10:01:13

I wouldn't think so. It operates on a hashmap.

Alex Miller (Clojure team)14:01:13

no, it's not predictable

Alex Miller (Clojure team)14:01:32

you could exclude the plexus-util in whatever branch and then it wouldn't matter, right?

slipset14:01:52

That's correct, and what I ended up doing.

avi17:01:12

Does tools.deps.graph support gitlibs?

avi17:01:25

Hmm, I see, it looks like maybe not when --size is specified?

avi17:01:46

which makes sense, but perhaps it would be good to display an error message rather than a stacktrace…

avi17:01:55

/Users/avi.flax/.gitlibs/libs/expound/expound/9b5778a1a4ed91e2090308a6648ee9072076925a is not a relative path
java.lang.IllegalArgumentException: /Users/avi.flax/.gitlibs/libs/expound/expound/9b5778a1a4ed91e2090308a6648ee9072076925a is not a relative path
	at $as_relative_path.invokeStatic(io.clj:414)
	at $file.invokeStatic(io.clj:426)
	at $file.invoke(io.clj:418)
	at clojure.tools.deps.alpha.extensions.git$eval1027$fn__1029.invoke(git.clj:43)
	at clojure.lang.MultiFn.invoke(MultiFn.java:239)
	at clojure.tools.deps.graph$get_size.invokeStatic(graph.clj:95)
	at clojure.tools.deps.graph$get_size.invoke(graph.clj:93)
	at clojure.tools.deps.graph$make_dep_node.invokeStatic(graph.clj:107)
	at clojure.tools.deps.graph$make_dep_node.invoke(graph.clj:99)
	at clojure.tools.deps.graph$make_graph$fn__1522.invoke(graph.clj:125)

Alex Miller (Clojure team)17:01:18

That’s possible, I thought I tested that, but maybe not. It’s supposed to fall back to 0 in that case

avi17:01:09

Would you like a bug report somewhere?

Alex Miller (Clojure team)17:01:09

I’ll take a look when I get a chance

avi17:01:54

BTW when you do take a look at this, I’m thinking maybe using 0 for gitlibs is a little misleading? It’s more of an unknown… perhaps something like -1 or “unknown” or :man-shrugging: or just leaving it blank…?

avi17:01:42

BTW reviewing the deps graph for my project is fascinating, and very informative — thank you!

Alex Miller (Clojure team)17:01:38

Sorry size isn’t working!

avi17:01:34

No big deal!

avi17:01:15

It’s already immediately obvious that I have a single dep bloating my project. It’s a dep I’ve been planning to drop eventually, so now I’m even more motivated to so do!

avi17:01:25

Here I’ve manually highlighted that dep and all its deps — it’s pretty dramatic!

Alex Miller (Clojure team)17:01:15

nice - I'd like to also have an output mode to export the dot file itself instead of the image so you can further mess with it

avi17:01:49

Interested in PRs?

Alex Miller (Clojure team)17:01:26

nah, it's part of other changes I want to make

👍 4
🙏 4
avi17:01:41

:thinking_face: it’d be cool if there was a feature to assign a unique background color to each branch from the root — might make it easier to visualize the impact of each root-level dep

Alex Miller (Clojure team)18:01:43

you could drop that in a question at https://ask.clojure.org if you want, category of "Contrib libs / tools.deps.graph" and label "request"

👍 4
Alex Miller (Clojure team)18:01:13

worth playing with. I experimented with a variety of color things, never found something that I thought helped, but I didn't try that!

avi18:01:20

Cool, will do!

seancorfield21:01:17

@alexmiller A question about tools.deps.graph: it seems that it reads just the current deps file so if you have overrides provided in another deps file, it won't see them? At work we have a "user-level" deps file in the monorepo that "pins" versions of everything via a :defaults alias and then we have {} for deps in each project deps.edn file.

seancorfield21:01:36

Can I specify multiple deps.edn files to read/merge on the command-line?

seancorfield21:01:53

(so far everything I've tried in the context of our work repo has either failed outright or produces a blank canvas claiming the size is -1 x -1)

seancorfield21:01:47

If I generate to a file, I seem to get a graph as expected, so it's perhaps only the default render to a graphics window that fails...

Alex Miller (Clojure team)21:01:27

in that it uses mostly the identical code

Alex Miller (Clojure team)21:01:44

so, no you can't use multiple deps.edn files

seancorfield21:01:10

Ah, I was confused by the results I was seeing... it does take the user-level deps into account after all?

Alex Miller (Clojure team)21:01:37

unless I'm misremembering that

seancorfield21:01:08

build [ graph api -a :defaults -o /tmp/graph.png ]
which ends up being
cd api; CLJ_CONFIG=../versions clojure -A:graph:defaults -a :defaults -o /tmp/graph.png
does indeed produce the correct graph for our api subproject. I think getting the blank popup was throwing me off there.