diff options
author | Bundlerbot <bot@bundler.io> | 2019-12-16 20:08:32 +0000 |
---|---|---|
committer | Bundlerbot <bot@bundler.io> | 2019-12-16 20:08:32 +0000 |
commit | f54ae4f4b2e287792f53410dec42e6b26b3dfcaa (patch) | |
tree | abc352c2fd89a692bf82d0e247894accce9d1abc /CHANGELOG.md | |
parent | 4045ba4bb1b19c8c43178daae1918f38d11c6af6 (diff) | |
parent | 8ce0824c39cc35e179ce43678b3f8bb3f798abc6 (diff) | |
download | bundler-f54ae4f4b2e287792f53410dec42e6b26b3dfcaa.tar.gz |
Merge #7493
7493: Fix another silent rubygems issue r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we still have some issues where using the `gem` script on a `bundler` context is silenced.
### What was your diagnosis of the problem?
My diagnosis was that `bundle exec` adds `-rbundler/setup` to RUBYOPT which silences `rubygems` output, and that we need to reset `rubygems` UI after that so that if we end up shelling out to `gem`, it is not silent. The previous approach worked for loading the `gem` script in-process, but didn't work in other case.
### What is your fix for the problem, implemented in this PR?
My fix is to reset rubygems UI right after `bundler/setup`.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem independently of the rubygems version being run, but we can probably also fix this more cleanly inside the `gem` script by adding something like `Gem::DefaultUserInteraction.ui = Gem::ConsoleUI.new` at the top of the script.
Fixes #7490.
Co-authored-by: David RodrÃguez <deivid.rodriguez@riseup.net>
Diffstat (limited to 'CHANGELOG.md')
0 files changed, 0 insertions, 0 deletions