Comment made by: chrisn

https://dev.clojure.org/jira/browse/TDEPS-111

I think it would be best to file a new feature issue in TDEPS rather than continuing here. I don't think I would want to take the change you're suggesting in the fork, but would be good to have a new ticket to discuss what a thing might look like.

Without doing too much thinking about it, I would probably suggest some kind of event based api as the most flexible thing.

Comment made by: chrisn

I currently use (-> canonicalize expand-deps):

https://github.com/cnuernber/depsviz/blob/master/src/cnuernber/depsviz/tools_deps.clj#L18

I hacked around in the library for a while and have a patch that passes all the tests but also allows the expand-deps pathway to find dependency conflicts:

https://github.com/cnuernber/tools.deps.alpha/commit/3607b26fbe683fa63c701a957dc7c01c61a56227

I think it is not too much trouble for me to maintain this fork. My use case is special and probably not ideal for the average users; I want to explicitly traverse as much of the potential graph including conflicts as possible and highlight as many conflicts as possible. Most users want to traverse as little as possible as long as the resolution mechanism is consistent but transitive dependencies change and thus their expected behavior of their programs changes.

The great thing about deps.edn is that it was trivial for me to include an unpublished branch that I can ensure always works for my use case. So it is overall a win; I am not sure how much build tooling really does want to know all the possible dependencies. It increases your test manifold significantly for you to include such functionality as a reference.

tools.deps does not yet have any public feature to describe the dependency choices, so I'm not sure what you're using for this. If it's the :verbose flag - that is not considered public api and is subject to change, removal, and change without warning.

I would like to have features that could expose more of this information to users, but I expect that feature would be something completely new.

Comment made by: chrisn

Hey, sorry I didn't check this out sooner but the chosen fix breaks any dependency viewer based on tools.deps; users cannot see why a particular dependency is chosen or where all conflicts have occurred.

I am reading through the code now to figure out what a middle ground is with the issue or if there is a middle ground at all.