`gem content NAME` outputs nothing after upgrading to 2.1.0

[doudou]

I've just updated to 2.1 a system that uses Bundler to install a bunch of gems. This system calls scripts/CMake code which itself tries to detect some gem parameters using gem content. Until 2.1 this worked fine.

I've locally upgraded to 2.1 today, and now gem content NAME just outputs nothing. The system I'm maintaining is using Bundler programatically, so I wonder if it could be an expected change of behavior ?

From the command line, if I run

RUBYOPT=-r/home/doudou/.local/share/autoproj/gems/ruby/2.5.0/gems/bundler-2.1.0/lib/bundler/setup \
  GEM_HOME=/home/doudou/.local/share/autoproj/gems/ruby/2.5.0 \
  BUNDLE_GEMFILE=/home/doudou/dev/build_area/bundler2.1/install/gems/Gemfile \
  gem2.5 content rice

I get no output. Removing the RUBYOPT solves it. Would anyone have an idea about why this started appearing ?

[doudou]

There seem to have a difference in behavior if gem2.5 is executed by bundle exec directly, or through an intermediate shell.

Setup:

mkdir install
mkdir gem
echo 'source "https://rubygems.org"' > install/Gemfile
echo 'gem "tty-progressbar"' >> install/Gemfile
BUNDLE_GEMFILE=$PWD/install/Gemfile GEM_HOME=$PWD/gem bundle install

Then the following works

BUNDLE_GEMFILE=$PWD/install/Gemfile GEM_HOME=$PWD/gem \
   bundle exec gem content tty-progressbar

But this does not display anything:

BUNDLE_GEMFILE=$PWD/install/Gemfile GEM_HOME=$PWD/gem \
    bundle exec sh -c "gem content tty-progressbar"

[doudou]

It looks as if the output is somehow closed/redirected. Providing a non-existent gem does exit with status 1, but displaying nothing

BUNDLE_GEMFILE=$PWD/install/Gemfile GEM_HOME=$PWD/gem \
    bundle exec sh -c "gem content doesnotexist"
echo $?

outputs

1

while

BUNDLE_GEMFILE=$PWD/install/Gemfile GEM_HOME=$PWD/gem \
    bundle exec gem content doesnotexist
echo $?

outputs

Unable to find gem 'doesnotexist' in default gem paths

Directories searched:

1

[doudou]

So, could track it down to general UI handling. As far as I could understand, Bundler's UI setup takes over the RubyGems UI and basically silences it forever (https://github.com/bundler/bundler/blob/2-1-stable/lib/bundler.rb#L89).

This behavior was added by a3260aa9d173388636a16e269da71bdb1464c9c9. The PR picked 'debug' as the level for all RubyGems message, which obviously silences them in the default setup. Since the ui is initialized when loading bundler/setup.rb, it applies to rubygems when loaded under bundler.

bundler exec gem works because the UI is reset before the ruby script is executed. It fails in the shell because setup.rb gets reloaded and the UI is overtaken again.

One possible "fix" would be to avoid overtaking the rubygems UI when loading setup.rb (but let bundler-the-CLI-tool unchanged).

Changing the level would work right now (use 'info' instead of 'debug'), but will fail if for whatever reason Bundler's current log level is higher than 'info'.

Thoughts anyone ?

[deivid-rodriguez]

One possible "fix" would be to avoid overtaking the rubygems UI when loading setup.rb (but let bundler-the-CLI-tool unchanged).

Yes, this makes sense to me, let me try fix it.

[doudou]

One possible "fix" would be to avoid overtaking the rubygems UI when loading setup.rb (but let bundler-the-CLI-tool unchanged).

Yes, this makes sense to me, let me try fix it.

Thanks for looking into it ... Appreciated.

[nicolas-brousse]

I've similar issue by simply doing the following

% pry
[1] pry(main)> `gem --version`
=> "3.1.1\n"
[2] pry(main)> require "bundler/setup"
=> true
[3] pry(main)> `gem --version`
=> ""

Versions

% ruby --version
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin18]
% gem --version 
3.1.1
% bundle --version
Bundler version 2.1.0
% gem list bundler

*** LOCAL GEMS ***

bundler (default: 2.1.0)