Errors during automatic require are swallowed

[indirect]

When Bundler.require is called by e.g. Rails, Bundler will try to require every gem listed in the Gemfile. If there is an error while requiring said gem, Bundler will completely suppress the error, and instead print its own error with the message "there was an error requiring 'some_gem'". At an absolute minimum, we should print the underlying exception message, and we should probably also mention that you can use verbose/debug mode to see the backtrace.

For example, the code require 'coffee-rails' will check for a JavaScript interpreter, and raise an error if none is found. That error looks like this:

irb(main):001:0> require 'coffee-rails'
ExecJS::RuntimeUnavailable: Could not find a JavaScript runtime. See https://github.com/rails/execjs for a list of available runtimes.

If you have a Gemfile with coffee-rails in it, however, calling Bundler.require will instead print this singularly useless message:

/usr/local/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/runtime.rb:80:in `rescue in block (2 levels) in require': There was an error while trying to load the gem 'coffee-rails'. (Bundler::GemRequireError)
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/runtime.rb:76:in `block (2 levels) in require'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/runtime.rb:72:in `each'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/runtime.rb:72:in `block in require'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/runtime.rb:61:in `each'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/runtime.rb:61:in `require'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler.rb:99:in `require'
    from /var/web/releases/20151223030515/config/application.rb:5:in `<top (required)>'

[maclover7]

Looks like this was solved by #4187 - ready to close?

[FooBarWidget]

We're getting a lot of support requests in the Passenger support channels about exactly this problem. People deploy an app to Passenger, finds that Bundler bails out with a GemRequireError and then don't know what to do next because the original error is swallowed. Could you release the fix sooner? Right now lots of users are confused.

[indirect]

@FooBarWidget the fix is already released in the 1.12 release candidate. How about you ask your users to test it, so we can find out if it's safe to do a final release?

[segiddins]

It's in the 1.12 betas

[FooBarWidget]

But that's the thing, it's a beta. While the more adventurous users would be willing to install the beta to test things, other users would not so easily dare to do that. Can't you backport the fix to the 1.11 series so that it can more quickly fixed? Or will 1.12 be final real soon? It seems the bug has been in the wild for several months now.

[indirect]

@FooBarWidget We just pushed the release candidate, as I said. That means if no bugs are discovered, it is the final release.

Furthermore, demanding that we do a release because the lack of release is inconvenient for you is rude and entitled—Phusion doesn't help maintain Bundler, and doesn't contribute money to Ruby Together so we can afford to maintain it. We'll release when we're ready, end of story. Demands make us less likely to want to help you, not more likely.

[FooBarWidget]

@indirect I am confused why you saw my messages as a demand. I apologize if I offended you somehow, but it certainly wasn't meant as a demand. Maybe you have had bad experience with demanding users lately, but as far as I'm concerned I was politely asking for a faster solution, and in my opinion not without good reasons.

You say that the final is imminent. Good. But I had no way of knowing that. I only knew the facts:

• The issue was introduced in 1.11.0, 12 december 2015, so the issue has been in the wild for 3 months now.
• The first time I discovered this issue was a month ago. I found out that the issue had been fixed in git master, but nothing seemed to indicate when the fix will be released.
• Today I checked again and I saw that there had been several release candidates, the last one from 3 weeks ago. But I had no visibility in your release roadmap. Maybe it's imminent for you, but before you told me about it the final might as well be another 3 months from now.

So yeah, I know just as well as you how it is to maintain an open source project and the economics of it. Sure it's entirely your right to release whenever you want. But all I was doing was politely asking you to consider the real casualties here: our users. I don't really care about the issue, but users are confused. I'm just communicating with you on behalf of them.

[indirect]

@FooBarWidget we're aware of the bug and the confused users, and that's why we have fixed the bug and released a version of Bundler with the fix that anyone can use.

I'm not sure where you were looking for release candidates, but we have only released one, and it was three days ago. Here's the list from rubygems.org/gems/bundler:

• 1.12.0.rc - March 14, 2016 (275 KB)
• 1.12.0.pre.2 - February 26, 2016 (269 KB)
• 1.12.0.pre.1 - February 9, 2016 (267 KB)

We've been trying to get 1.12 out as fast as we can. When you started with "We're getting a lot of support requests in the Passenger support channels about exactly this problem." and concluded with "Could you release the fix sooner? Right now lots of users are confused.", it makes it sound like you want us to stop whatever paid work we're doing and instead do unpaid open source work to speed up the release in order to make your (paid!) job easier. Asking for our uncompensated labor in order to make your compensated labor easier—that's the part that sounds demanding and entitled.

[FooBarWidget]

I'm not sure where you were looking for release candidates,

I was looking in your changelog: https://github.com/bundler/bundler/blob/master/CHANGELOG.md
No mention of a release candidate there. Plus, you talked about "release candidate" while @segiddins talked about "betas", which added to the confusion.

We've been trying to get 1.12 out as fast as we can.

I appreciate that you have been working as quickly as you can. I was only asking you to reconsider this issue's priority. In fact, I used the phrase "could you" deliberately. I remember that years ago my English teacher told me that "could you" is used as a polite request, e.g. as opposite to "you must" or the more explicitly "I demand" etc. "Could" is supposed to be one of the politest forms to ask for something. Maybe you can see how I'm confused that you interpret my request as being a rude demand.

Naturally the one who makes the final planning is you. I don't expect otherwise. I can understand how frustrated you must be at entitled users, I am too, but please know that I'm not one of them. My comment was a way to open a dialog to see what can be done about the issue at hand, not a way to demand things.

If your position is that any request at all from a paid worker can only be considered entitled and demanding, and that there is no way to politely request something and to discuss things, then I am afraid the discussion ends here. The only thing I can do is to tell you what my intentions are.

[indirect]

Thanks for explaining what you meant.

The answer to "could I release" is always yes, but in order to do that I would have to stop doing work that is paying my rent. It's frustrating to even be asked the question, because it implies that your problem that needs a release is more important than whatever is keeping me from releasing.

For future reference, one way you can sound less demanding is by asking for information rather than actions: "Do you have an idea yet of how soon the next release will be?" sounds like you would like to know when the next release will be, but you aren't implicitly placing your own problems above mine.

[FooBarWidget]

All right. So do you have an idea of when the final will be? :)

[indirect]

Yes! We always allow at least 7 days for users to report bugs in each release candidate. Depending on how things go, we may allow up to 14 days for users to report bugs. That means we plan to release 1.12 final between March 21 and March 28 (as long as no significant bugs are discovered).

[mearleycf]

Trying out 1.12.0.rc, much more helpful so far! Thank you.