This code meant that _any_ gem install failure resulted in a message requesting the user to report this "bug" to the Bundler issue tracker. That is very, very not cool, and I had already fixed this issue once before the hook pull request regressed it. :(
Restoring the original ENV generally restored the RUBYOPT changes, but certain use cases leak through. This commit ensures that the ENV is truely clean by always checking for RUBYOPT changes and zapping them if they do exist. This commit fixes #1604 (second attempt)
Conflicts: CHANGELOG.md lib/bundler/version.rb
Conflicts: CHANGELOG.md lib/bundler/version.rb spec/install/gems/simple_case_spec.rb
This allows users to tell Bundler where to put the binstubs for system gems, much like the -n option in ~/.gemrc for Rubygems. If you set one, it probably makes sense to set the other. If you don't set system_bindir, though, Bundler will install system binstubs into Gem.bindir, regardless of what Rubygems does. refs #1417
Conflicts: CHANGELOG.md lib/bundler/cli.rb lib/bundler/installer.rb lib/bundler/version.rb
--- Dont hose existing load paths if Bundle.setup is called multiple times with a different set of groups. This fixes #1230.
Conflicts: .travis.yml lib/bundler.rb lib/bundler/source.rb
(re-enabling Bundler 1.0.x compatibility on Rubygems 1.8.10)
…imes with a different set of groups.
with_clean_env => with_original_env and other goodies [closes #900]