`bundle viz` should not require gems to be installed

[chriseppstein]

I wanted to use this command to diagnose installation issues so I know what to upgrade. But when things don't install, I get an error:

$ bundle viz
#=> Could not find ffi-0.6.3 in any of the sources

[indirect]

When things don't install, there is no graph. The graph is a visualization of the output from the resolver, so the resolver has to be able to complete successfully for there to be a graph. Perhaps you're looking for bundle outdated? Although that command also requires that you have successfully installed in the past, since it looks for gems that are outdated.

On Oct 3, 2011, at 1:00 PM, Chris Eppstein wrote:

I wanted to use this command to diagnose installation issues so I know what to upgrade. But when things don't install, I get an error:

$ bundle viz
#=> Could not find ffi-0.6.3 in any of the sources

Reply to this email directly or view it on GitHub: https://github.com/carlhuda/bundler/issues/1471

[chriseppstein]

Even if there are un-resolvable dependency conflicts a (disconnected) graph could be generated, right?

[indirect]

That is theoretically possible, but the viz command doesn't work that way right now. I'm pretty sure that would also require a different kind of resolver than the one we currently have (which quits at the first error).

[chriseppstein]

There is certainly a graph even if things don't install. You had to resolve before you could even know what to install.

Going further to the point a resolution-less graph is only a nice to have, but even if it only printed the part of the graph that was constructructed to the point of the first conflict would be useful for debugging dependency conflicts.

[raggi]

Even if there are un-resolvable dependency conflicts a (disconnected) graph could be generated, right?

No.

Whilst it's easy to assume that the graph consists of names and possible versions at the nodes, and edges that contain constraints, that's actually not the case.

Different versions of gems not only have different version constraints on their dependencies, but they can have entirely different dependencies.

To make the problem even worse, some of those gems have multiple "platforms", and each platform has some differences. There are also external conditions, such as required_rubygems_version and required_ruby_version.

The relatively naive (but also exceedingly simplistic) model that bundler uses, is a recursive generation + reduction model. The entire graph or subgraph are never generated, because to do so would be VERY computationally expensive, and very memory expensive.

It could be done in theory, with a different algorithm / mechanism, but the cpu and space requirements would remain. It's also possible that unresolved graph generation can lead to hard-to-identify cycles, adding further load on the algorithm and the system (especially if you're trying to merge nodes by gem name).

In short, again, this is actually a lot more complicated than it might first appear.

The best resolver I have seen solving a related problem is dep_selector, that was built for a similar purpose for chef cookbooks (but doesn't currently support all the gem requirement constraints, gem version patterns, platforms, and non-version constraints (ruby-version, rubygems-version)). It uses quite a nice package for constraint solving called gecode

[raggi]

It's worth noting that you don't need the gems installed to resolve the graph, but you do need the specifications.

[chriseppstein]

Listen guys. The point is that if conflicts happen in the bundling process, there is no obvious way to understand why. This means that debugging a bundle that won't install is a difficult process and it needn't be. Bundler should provide a way to diagnose gem conflicts in a way that shows the user which explicit gem dependencies are causing the conflict. It doesn't have to be fast or memory efficient -- any information is better than none.

[indirect]

Bundle viz is not the place to get that information. The error message from Bundler should just list the dependency chain that resulted in the error. As I recall, complex dependency conflicts are rare enough that no one (including me) has fixed the error to correctly print the entire dependency chain that caused the conflict. That's something I'd like to fix, but it's a separate problem from "bundle viz won't print a graph of the entire dependency resolution problem space so I can do my own resolution". :)

[chriseppstein]

It certainly is. Please fix however you see fit.

[mscottford]

Based on the discussion above, I reach two conclusions.

• It sounds like a new issue should be created to improve the output when there's a dependency conflict. Was that done? Is that still an issue?
• This issue should be closed.

Thoughts?

[indirect]

@mscottford sounds good to me. I believe there's an open ticket (probably by me) about fixing the error message for nested child dependencies.