Fork me on GitHub

So I have a (pruned) dependency tree that looks like this

├── a 1
│   └── b 1
│       └── x 2
│           └── y 1
└─── c 1
    └── x 1
        └── z 1
and my result when doing clj -Stree is the following:
org.clojure/clojure 1.9.0
  org.clojure/core.specs.alpha 0.1.24
  org.clojure/spec.alpha 0.1.143
c path-to-c 1
a path-to-a 1
  b path-to-b 1
    x path-to-x 2
      y path-to-y 1
      z path-to-z 1
I'm guessing this is a bug? I would love to send a reproducible example, but it's a bit hard without polluting my GitHub profile. Maybe adding an option to include local git repositories for :git/url would be an idea?


would a gist pollute your github profile?


some things that would be helpful: - version info from clj -Sverbose (I’m assuming you’re on latest, but if not, then there were significant changes to resolution in - output from adding -Sdeps '{:aliases {:v {:verbose true}}}' -R:v


with that I probably don’t need the reproducible deps.edn


this is the trickiest kind of version resolution issue - when you have different versions of a dep and the lib sets (not just the versions) are changing across them.


I’m assuming that what you expect here is to have a1, b1, x2, y1, c1 as the output (and no z1)


version      =
install_dir  = /usr/local/lib/clojure
config_dir   = /home/jeannikl/.clojure
config_paths = /usr/local/lib/clojure/deps.edn /home/jeannikl/.clojure/deps.edn deps.edn
cache_dir    = .cpcache
cp_file      = .cpcache/674722798.cp
Nothing in /usr/local/lib/clojure/deps.edn or /home/jeannikl/.clojure/deps.edn @gfredericks: That's a good idea, forgot about gists


Also yes, I'd expect z1 to not be present


which leads me to believe its most likely a path comparison issue with git deps


the verbose output should be sufficient for me to track that down


Huh, it seems like it depends on the order of the elements in the map.


Almost done with the gists now, one sec

hypirion15:03:45 If I flip the dependencies around in that repo, it doesn't include z.


I'm still a bit unsure about how the algorithm works, but I think it should be possible to walk the dependency tree at the end. If you can't reach a dependency by walking the tree, then don't include it as a dependency you need.


I have to run but will look at it later


That’s being done but it relies on comparing deps up the path


If the same dep has two different representations then that path matching will fail. That shouldn’t happen, but that’s my suspicion


@alexmiller: I flipped the order of the dependencies in your test case and mvn test fails on my machine with that change.


Interesting, well I guess I was just lucky :)


heh, yeah. Dependency algorithms are hard to get right