Standalone bundle's setup.rb should implement Gem.try_activate to avoid breaking binding.irb

[ntl]

Describe the problem as clearly as you can

I set --disable-gems in my RUBYOPT variable.

binding.irb causes a call to Gem.try_activate whenever the Gem constant is defined.

Standalone bundles include a bundler/setup.rb file, which defines the Gem constant even when Rubygems isn't required.

Thus, for me, binding.irb doesn't work with standalone bundles.

Did you try upgrading rubygems & bundler?

No, because I can see that Bundler's implementation is still incorrect: https://github.com/rubygems/rubygems/blob/master/bundler/lib/bundler/installer/standalone.rb#L79-L97

Post steps to reproduce the problem

• export RUBYOPT=--disable-gems
• Install a standalone bundle
• After requiring bundler/setup from the standalone bundle, add a binding.irb statement
• Observe the undefined method error on Gem.try_activate

Which command did you run?

bundle install --standalone

What were you expecting to happen?

binding.irb to work

What actually happened?

binding.irb didn't work

If not included with the output of your command, run bundle env and paste the output below

Not sure how to do this

[deivid-rodriguez]

Hei @ntl.

Thanks for the report and sorry for getting to it so late.

I don't think irb needs Gem.try_activate at all, so I proposed removing it here.

However, most usages of RubyGems methods out there are indeed guarded by defined?(Gem) and that will indeed break standalone scripts generated by Bundler.

I think we should avoid defining a Gem module at all. If Gem is available, use the necessary methods, otherwise defining the methods in a different place.

Since we only need Gem.ruby_api_version and Gem.extension_api_version, I wonder if it would make sense to propose moving them to RbConfig.

[ntl]

@deivid-rodriguez that makes sense. In my experience, another very common use of Gem that I've encountered is Gem::Version, for version comparisons.

I actually believe that Gem.ruby_api_version is itself just a wrapper around RbConfig::CONFIG['ruby_version'], and Gem.extension_api_version seems to source its value from Gem.ruby_api_version unless Ruby is statically linked.

[deivid-rodriguez]

Yes, indeed they seem super simple wrappers around RbConfig::CONFIG, hence my suggestion of moving them there.

• Gem.ruby_api_version could probably be moved to RbConfig.ruby_api_version, and deprecate Gem.ruby_api_version in favor of that.
• Gem.extension_api_version could get a new key in RbConfig::CONFIG and then expose RbConfig.extension_api_version as a way to access it, deprecating Gem.extension_api_version similarly.

The alternative if this proposal was not accepted by ruby-core would be to define the methods in a new top level module unlikely to have been user defined, like StandaloneBundleGem or something like that.

[ntl]

Ah, after reading through the issue you linked, I think I see where you're going with this.

I'd love to see standalone bundles work in conjunction with ruby --disable-gems. This seems to be the most straightforward path to being able to decouple the package manager from build artifacts. That way, Ruby projects could be deployed to servers that don't have Rubygems installed at all..

Thanks for the work on this and other issues I've filed!