Deprecate --default option from install command
#7588
Conversation
hsbt
force-pushed
the
deprecate-default-option
branch
from
0e48c8e
to
87b194f
Compare
hsbt
force-pushed
the
deprecate-default-option
branch
4 times, most recently
from
89277af
to
0f34a74
Compare
hsbt
force-pushed
the
deprecate-default-option
branch
from
0f34a74
to
dc83e45
Compare
|
@hsbt I agree with this approach. The |
|
👌 It's ready for review now. |
There was a problem hiding this comment.
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.
| ) | ||
| installer.install | ||
| File.delete installer.spec_file | ||
| installer.write_default_spec |
There was a problem hiding this comment.
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.
| "Add the gem's full specification to", | ||
| "specifications/default and extract only its bin") do |v,_o| | ||
| options[:install_as_default] = v | ||
| end |
There was a problem hiding this comment.
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.
What was the end-user or developer problem that led to this PR?
The current
--defaultoption is confused for RubyGems users.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