This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-13
Channels
- # aleph (1)
- # announcements (14)
- # aws (8)
- # babashka (3)
- # beginners (49)
- # cider (6)
- # clara (7)
- # clj-kondo (58)
- # cljs-dev (17)
- # clojure (65)
- # clojure-dev (45)
- # clojure-europe (5)
- # clojure-italy (4)
- # clojure-nl (25)
- # clojure-norway (3)
- # clojure-uk (68)
- # clojurescript (10)
- # cursive (5)
- # datomic (12)
- # emacs (24)
- # fulcro (149)
- # hoplon (56)
- # kaocha (2)
- # luminus (18)
- # malli (7)
- # off-topic (12)
- # other-languages (82)
- # reagent (16)
- # reitit (7)
- # shadow-cljs (44)
- # spacemacs (4)
- # tools-deps (48)
- # xtdb (17)
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
.
One reaction to this would of course be 🤷 , but from https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html we have that
> Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins.
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.
Thinking of it, I’m not sure why I’m writing this, I guess it’s just as an amusing story.
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?
no, it's not predictable
you could exclude the plexus-util in whatever branch and then it wouldn't matter, right?
which makes sense, but perhaps it would be good to display an error message rather than a stacktrace…
/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)
That’s possible, I thought I tested that, but maybe not. It’s supposed to fall back to 0 in that case
I’ll take a look when I get a chance
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…?
BTW reviewing the deps graph for my project is fascinating, and very informative — thank you!
Sorry size isn’t working!
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!
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
: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
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"
worth playing with. I experimented with a variety of color things, never found something that I thought helped, but I didn't try that!
@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.
Can I specify multiple deps.edn
files to read/merge on the command-line?
(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
)
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...
it's the same as clj
in that it uses mostly the identical code
so, no you can't use multiple deps.edn files
Ah, I was confused by the results I was seeing... it does take the user-level deps into account after all?
it should
unless I'm misremembering that
yeah, it does
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.