Feature request/proposal: bundle why gem

[zverok]

Idea is borrowed from newly arrived YARN package manager. Shown, for example, in this twit

Idea is, something like that:

bundle why gemname
# output 1:
gemname 1.14 installed because required explicitly in Gemfile, group :development
# output 2:
gemname 1.14 installed because required by othergemname 2.03 (Gemfile, group :testing)
# more complicated:
gemname 1.14 installed because required by othergemname 2.03 => thirdone 0.19 => fourthgem 0.0.1 (Gemfile, group :runtime)
# and this one
gemname 1.14 installed because required by othergemname 2.03 (Gemfile, group :testing) and thirdone 0.19 (Gemfile, group :runtime)

Utterly naive implementation (not doing all what is proposed, just showing it is possible; also, really quickly dropped in bad Ruby) shown here

If an idea itself is acceptable (and I am not missing it is already possible/done), I can prepare proper PR with good design, specs and stuff.

[segiddins]

This could also use the raw dependency graph that molinillo gives us at the end of resolution, or by following the graph that SpecSet holds, but at the end of the day this feels more like plugin functionality to me (and I'd personally prefer bundle explain, since it seems more verb-y to me)

[indirect]

I like bundle explain and the idea of this as a plugin. To be super clear, though, you can already get this effect by opening your Gemfile.lock and then searching for the gem name. It will show up, indented, under any gem that requires it.

[zverok]

This could also use the raw dependency graph that molinillo gives us at the end of resolution, or by following the graph that SpecSet holds

Yep, I'll investigate the possibilities, first solution was just really the first way to it I've came up with (just to check there is enough information in internal structures to do it).

but at the end of the day this feels more like plugin functionality to me (and I'd personally prefer bundle explain, since it seems more verb-y to me)

I like bundle explain and the idea of this as a plugin.

Got it. Will do.

To be super clear, though, you can already get this effect by opening your Gemfile.lock and then searching for the gem name. It will show up, indented, under any gem that requires it.

Yep, of course I understand this. Just not geeky enough for me (too much manual work to quickly answer simple question).

[zverok]

Fix me if I am wrong: plugin system is still in development, right? Guessing from #3463 and http://bundler.io/whats_new.html#experimental-plugin-system?.. So, there are only some preliminary possibilities for writing plugins, are they documented anywhere?..

[indirect]

@zverok you can completely ignore the plugin system for now, and create a gem that installs the command bundle-explain. When your gem is installed and a user runs bundle explain foo, Bundler will look for bundle-explain in the $PATH, and exec to bundle-explain foo. 👍

[mjreed-wbd]

You can only use the Gemfile.lock if the bundle install succeeds. Otherwise, no lock, no dependency graph. I want to know why Bundler is even trying to install a given gem in the first place, but if that installation fails, I can't find that out.

If I'm wrong, please tell me so. But as far as I can tell, today, if I get a message from 'bundle install' that it fails because there is no compatible version of gem X, which is not in my Gemfile, the only way I can find out which of the gems in my Gemfile wind up ultimately requiring gem X is to somehow manage to get some permutation of the set of gems in my Gemfile to install successfully so that I can run [bundle exec] gem dependency.

[segiddins]

If installation fails, the error message for the version conflict should be sufficient to explain why that dependency was included. If it is not, please open up a separate issue.

[indirect]

@segiddins I believe this request is about gems that fail to install, after a successful resolution. e.g. “what why is it trying to install pgsql?! I don’t depend on that”

[markjreed]

@indirect exactly. resolution succeeds, but isn't documented in the Gemfile.lock because the actual install fails and aborts the installation. So the resolution is nowhere visible, and there is no way to determine why it was trying to install the gem that failed.

[segiddins]

Thanks for the clarification! So it's really the "resolution succeeds" but actually installing a gem fails case, and we print "try seeing if gem install ... works", we should print the different gems that caused "foo" to be required in the first place. Is that correct?

[markjreed]

@segiddins Yes, that would be very helpful.

[segiddins]

RuntimeError: install failed
An error occurred while installing activesupport (5.0.1), and Bundler cannot continue.
Make sure that `gem install activesupport -v '5.0.1'` succeeds before bundling.

In Gemfile:
  rails was resolved to 5.0.1, which depends on
    actioncable was resolved to 5.0.1, which depends on
      actionpack was resolved to 5.0.1, which depends on
        actionview was resolved to 5.0.1, which depends on
          rails-dom-testing was resolved to 2.0.2, which depends on
            activesupport

Would this sort of output be helpful?
(The example is a gemfile that contains rails, and installing activesupport has failed)

[markjreed]

Yes, that sort of output would be perfect!