Deprecate --default option from install command

[hsbt]

What was the end-user or developer problem that led to this PR?

The current --default option is confused for RubyGems users.

• cannot load such file -- /Users/jedrek/.rvm/rubies/ruby-2.7.7/lib/ruby/gems/2.7.0/gems/bundler-2.4.19/exe/bundle (LoadError) #7005
• rubygems test fail with latest dependencies #5951 (comment)

This option is special behavior for default gems. But I'm not sure why it only generate executable, not copy library files and other processes.

What is your fix for the problem, implemented in this PR?

It leads complicated environment and there is no merit for them. I don't allow that users install gem as default gems from core maintainer's view.

Finally, I'll show deprecated message and removed code about this option from rubygems.

Closes #7005.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[deivid-rodriguez]

@hsbt I agree with this approach. The --default option is problematic and causes broken installs. The easiest option would be to remove it and consider default gems fixed. Is this ready for review?

[hsbt]

👌 It's ready for review now.

[deivid-rodriguez]

Right now this PR is deprecating the flag, but changing the behavior by making the flag a noop and install the gem normally, correct?

I believe this may be acceptable, because I don't see how the current implementation is helpful. However, we currently document exactly what the flag does, so may be potentially useful for someone, and the more conservative approach would be to first deprecate the flag without changing behavior, and then remove everything.

I think the latter option is preferable, but open to do it differently.

[deivid-rodriguez]

I think this will install a full copy of bundler in the standard $GEM_HOME. I don't think it's a problem per se, but it makes Bundler inconsistent with other default gems with executables provided with Ruby (for example, irb, which includes a placeholder gem directory with just the executable).

We could try to iterate on this but perhaps for now it's better to not use Gem::Installer at all here and create the files necessary (executables, and gemspec) manually, to keep the exact same folder structure gem update --system creates now.

[deivid-rodriguez]

Should we use deprecate_option here, to also give a runtime deprecation message? The way it is right now, I think it only appears as deprecated in documentation.

[simi]

🤔 It seems it was never finished feature (according to #566).

[simi]

@headius is it ok to remove? Isn't that something JRuby specific? 🤔

[headius]

Wow, this goes back a ways.

When I originally added default gem support, I had intended --default to basically perform an install directly into the Ruby standard library location. Unfortunately I never finished that work and others who were more aware of how CRuby organizes its libraries were not available to help me fill in the blanks.

As it is now – a partially-implemented feature – it's obviously not very useful.

It would have been nice to get it fully working, but even then it's not something that should be user-facing; what we really want is something that can be used by Ruby implementers to install default gems into the standard library. CRuby and JRuby both have their own custom scripts to do this. TruffleRuby just copies out of the CRuby repository. None of these approaches are great.

I think it's fine to remove --default from RubyGems, but perhaps in its stead @hsbt and @nobu and I need to work on making our default gem installation logic more standard and shared.

[headius]

it's not something that should be user-facing

This may not entirely be true; there are probably users that would like to alter or update the "default" gems in their Ruby installs, and currently there's no way to do that without manually manipuating those gems' files. But I'm not sure what that functionality should look like.