Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

[2.0] Stop remembering CLI options in Bundler 2 #5811

Merged
merged 18 commits into from Jul 19, 2017

Conversation

segiddins
Copy link
Member

@segiddins segiddins commented Jun 22, 2017

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.

@bundlerbot
Copy link
Collaborator

☔ The latest upstream changes (presumably #5725) made this pull request unmergeable. Please resolve the merge conflicts.

@segiddins segiddins force-pushed the seg-stop-remembering-cli-options branch 4 times, most recently from b6532c5 to 9ded05f Compare July 11, 2017 20:35
@segiddins segiddins changed the title [WIP] [2.0] Stop remembering CLI options in Bundler 2 [2.0] Stop remembering CLI options in Bundler 2 Jul 11, 2017
@segiddins
Copy link
Member Author

I think this is no longer a WIP, so feedback (particularly on which options are removed/kept in 2.0) would be 🚀

@bundlerbot
Copy link
Collaborator

☔ The latest upstream changes (presumably #5843) made this pull request unmergeable. Please resolve the merge conflicts.

@segiddins
Copy link
Member Author

:all-of-the-conflicts:

@segiddins segiddins force-pushed the seg-stop-remembering-cli-options branch from 9ded05f to 347015f Compare July 18, 2017 01:32
Copy link
Member

@colby-swandale colby-swandale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@@ -53,6 +52,11 @@ def initialize(*args)
end
end

def self.forgotten_option(*args, &blk)
Copy link
Member

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.

Copy link
Member Author

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]
Copy link
Member

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?

Copy link
Member Author

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

@segiddins segiddins force-pushed the seg-stop-remembering-cli-options branch from 347015f to 289306e Compare July 18, 2017 16:41
@segiddins
Copy link
Member Author

Rebased, addressed Colby's conflicts, fixed specs.
@indirect please review

Copy link
Member

@indirect indirect left a 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. 👍

@@ -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 =>
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great 👍

@@ -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"
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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. :/

@@ -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."
Copy link
Member

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).

Copy link
Member Author

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!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@segiddins
Copy link
Member Author

I'd also like to deprecate init --gemspec, if that's okay with everyone else.

out of curiosity, why?

@segiddins segiddins force-pushed the seg-stop-remembering-cli-options branch from 289306e to 4d47b28 Compare July 19, 2017 19:04
@segiddins
Copy link
Member Author

@indirect think I got all of the ones you requested!

@indirect
Copy link
Member

This looks good 👍 I'd like to deprecate init --gemspec because I think it should be replaced by using gemspec in the Gemfile.

@segiddins segiddins force-pushed the seg-stop-remembering-cli-options branch from 4d47b28 to bc4b6c0 Compare July 19, 2017 20:54
@segiddins
Copy link
Member Author

Cool! Just fixed the one test failure, so r?

@indirect
Copy link
Member

@bundlerbot r+

@bundlerbot
Copy link
Collaborator

📌 Commit bc4b6c0 has been approved by indirect

@bundlerbot
Copy link
Collaborator

⌛ Testing commit bc4b6c0 with merge 53dfec6...

bundlerbot added a commit that referenced this pull request Jul 19, 2017
…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.
@bundlerbot
Copy link
Collaborator

☀️ Test successful - status-travis
Approved by: indirect
Pushing 53dfec6 to master...

@bundlerbot bundlerbot merged commit bc4b6c0 into master Jul 19, 2017
@segiddins segiddins deleted the seg-stop-remembering-cli-options branch July 20, 2017 15:41
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants