[2.0] Stop remembering CLI options in Bundler 2 #5811
Conversation
☔ The latest upstream changes (presumably #5725) made this pull request unmergeable. Please resolve the merge conflicts. |
b6532c5
to
9ded05f
Compare
I think this is no longer a WIP, so feedback (particularly on which options are removed/kept in 2.0) would be 🚀 |
☔ The latest upstream changes (presumably #5843) made this pull request unmergeable. Please resolve the merge conflicts. |
:all-of-the-conflicts: |
9ded05f
to
347015f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
lib/bundler/cli.rb
Outdated
@@ -53,6 +52,11 @@ def initialize(*args) | |||
end | |||
end | |||
|
|||
def self.forgotten_option(*args, &blk) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can i suggest removed_option
or deprecate_option
instead. This confused me a bit with the CLI no longer remembering options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I think I'll go with deprecated_option
@@ -66,6 +66,7 @@ def out_of_space_message | |||
end | |||
|
|||
def generate_executable_stubs | |||
return if Bundler.feature_flag.forget_cli_options? | |||
return if Bundler.settings[:inline] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return if Bundler.settings[:inline] || Bundler.feature_flag.forget_cli_options?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer having the two separate conditions, since they're basically unrelated
347015f
to
289306e
Compare
Rebased, addressed Colby's conflicts, fixed specs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd also like to deprecate init --gemspec
, if that's okay with everyone else.
Generally looking great, thanks for taking the lead on shipping this stuff. 👍
lib/bundler/cli.rb
Outdated
@@ -164,28 +168,28 @@ def check | |||
"Specify the number of jobs to run in parallel" | |||
method_option "local", :type => :boolean, :banner => | |||
"Do not attempt to fetch gems remotely and use the gem cache instead" | |||
method_option "no-cache", :type => :boolean, :banner => | |||
deprecated_option "no-cache", :type => :boolean, :banner => | |||
"Don't update the existing gem cache." | |||
method_option "force", :type => :boolean, :banner => | |||
"Force downloading every gem." | |||
method_option "no-prune", :type => :boolean, :banner => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should deprecate --no-prune
... afaik it was only added because of --cache
. Related, does the 2.0 cache
command effectively run install and then fill vendor/cache
? It should probably have a --prune/--no-prune
flag, to offer equivalent functionality that cache-users can migrate to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the 2.0 cache command is the 1.0 package command... it basically runs install && Bundler.load.cache
and it already has a --no-prune
flag. unrelated, but this reminds me we need to default cache_all_platforms
to true in 2.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great 👍
lib/bundler/cli.rb
Outdated
@@ -148,13 +152,13 @@ def check | |||
|
|||
If the bundle has already been installed, bundler will tell you so and then exit. | |||
D | |||
method_option "binstubs", :type => :string, :lazy_default => "bin", :banner => | |||
deprecated_option "binstubs", :type => :string, :lazy_default => "bin", :banner => | |||
"Generate bin stubs for bundled gems to ./bin" | |||
method_option "clean", :type => :boolean, :banner => | |||
"Run bundle clean automatically after install" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we deprecate this as well? I am pretty sure we can say "you can just run clean
, which will install
and then clean
". The concept of cleaning isn't even really coherent without an install happening first, imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure -- does this mean you'd like to default to cleaning or not after every install into a local path
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to default to cleaning if and only if the bundle is being installed into the default application-local .bundle
directory. If the user has provided some other "shared" location, I think cleaning should default to off. I'm worried that's possibly confusing, though. :/
lib/bundler/cli.rb
Outdated
@@ -164,28 +168,28 @@ def check | |||
"Specify the number of jobs to run in parallel" | |||
method_option "local", :type => :boolean, :banner => | |||
"Do not attempt to fetch gems remotely and use the gem cache instead" | |||
method_option "no-cache", :type => :boolean, :banner => | |||
deprecated_option "no-cache", :type => :boolean, :banner => | |||
"Don't update the existing gem cache." | |||
method_option "force", :type => :boolean, :banner => | |||
"Force downloading every gem." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like force
is a very unclear name for this option, and I'd like to deprecate it in favor of something like --redownload
. Or maybe better yet, a completely different command that nukes the cache, forcing downloads next time. (The latter is out of scope for this PR, though).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--redownload
sounds good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
out of curiosity, why? |
Since it did not cause the changed config to be written to disk
289306e
to
4d47b28
Compare
@indirect think I got all of the ones you requested! |
This looks good 👍 I'd like to deprecate |
4d47b28
to
bc4b6c0
Compare
Cool! Just fixed the one test failure, so r? |
@bundlerbot r+ |
📌 Commit bc4b6c0 has been approved by |
…irect [2.0] Stop remembering CLI options in Bundler 2 ### What was the end-user problem that led to this PR? The problem was that on Bundler 1.0, command line options passed to the different commands would be remembered _across command invocations_. This was hella confusing for users, and made Bundler a difficult command line tool to work with -- you'd pass an option once, it'd be set without you realizing it, and Bundler would behave differently. See https://trello.com/c/yGsPNDpg/48-stop-auto-remembering-any-command-flags for the original discussion, but I've excerpted bits below: > Silently remembering flags that were passed to a command sometime in the past completely breaks all expectations for how command-line utilities work. It’s convenient for some users some of the time, but at the cost of many, many bugs filed that turn out to be unexpectedly remembered options. ### Was was your diagnosis of the problem? My diagnosis was that, behind a feature flag, we'd change commands behavior to only set settings temporarily (for the life of the current process), and after that disable options that become useless when not remembered. See #3955. ### What is your fix for the problem, implemented in this PR? My fix is to remove most CLI options in Bundler 2. Those that remain are set only for the duration of the process, rather than persisted to disk.
☀️ Test successful - status-travis |
What was the end-user problem that led to this PR?
The problem was that on Bundler 1.0, command line options passed to the different commands would be remembered across command invocations. This was hella confusing for users, and made Bundler a difficult command line tool to work with -- you'd pass an option once, it'd be set without you realizing it, and Bundler would behave differently.
See https://trello.com/c/yGsPNDpg/48-stop-auto-remembering-any-command-flags for the original discussion, but I've excerpted bits below:
Was was your diagnosis of the problem?
My diagnosis was that, behind a feature flag, we'd change commands behavior to only set settings temporarily (for the life of the current process), and after that disable options that become useless when not remembered.
See #3955.
What is your fix for the problem, implemented in this PR?
My fix is to remove most CLI options in Bundler 2. Those that remain are set only for the duration of the process, rather than persisted to disk.