Fork me on GitHub
#tools-deps
<
2018-03-18
>
hypirion14:03:01

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?

gfredericks15:03:12

would a gist pollute your github profile?

alexmiller15:03:06

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 1.9.0.309) - output from adding -Sdeps '{:aliases {:v {:verbose true}}}' -R:v

alexmiller15:03:06

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

alexmiller15:03:59

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.

alexmiller15:03:52

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

hypirion15:03:09

version      = 1.9.0.358
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

hypirion15:03:27

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

alexmiller15:03:24

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

alexmiller15:03:49

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

hypirion15:03:41

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

hypirion15:03:54

Almost done with the gists now, one sec

hypirion15:03:45

https://gist.github.com/hypirion/b955e63ebb394c216c61fe1b1b6a48fd If I flip the dependencies around in that repo, it doesn't include z.

hypirion15:03:53

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.

alexmiller16:03:59

I have to run but will look at it later

alexmiller16:03:48

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

alexmiller16:03:08

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

hypirion16:03:05

@alexmiller: I flipped the order of the dependencies in your test case and mvn test fails on my machine with that change. https://github.com/hypirion/tools.deps.alpha/commit/5459773c7236e37d0306d1561d5dc5a42243ca70

alexmiller16:03:26

Interesting, well I guess I was just lucky :)

hypirion16:03:23

heh, yeah. Dependency algorithms are hard to get right