Deprecation messages recommending bundle config don't have the same effect as the old persisted flags

[eregon]

Describe the problem as clearly as you can

bundle config key value is --global by default (stored in ~/.bundle/config), while I think most usages would benefit from being local.

For instance, typical mistakes are bundle config path vendor/bundle, bundle config without db, etc.

Which unfortunately is also what is shown by deprecation messages, and I believe that part is an outright bug (Bundler 2.1.4) because the old flags did write to .bundle/config (= --local), fixed by #3917:

$ bundle install --path vendor/bundle
[DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set path 'vendor/bundle'`, and stop using this flag

$ bundle install --without db
[DEPRECATED] The `--without` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set without 'db'`, and stop using this flag

Note also that the very similar command git config key value defaults to --local.

I think it would be much safer and intuitive to change bundle config key value to also default to --local.
Most of Bundler configuration is project-specific and doing it globally makes often little sense, especially when not stating explicitly one wants it to be global.

[deivid-rodriguez]

I agree, we should fix the deprecation messages and consider changing bundle config default to be local 👍.

[eregon]

PR to fix the deprecation messages and always show --local/--global explicitly for bundle config set commands: #3917

[eregon]

cc @chrisseaton since you ran into this bug (but I'm sure you're not the only one, this exists since Bundler 2 IIRC).

[eregon]

Could we reopen to track changing the default? Or should I file a new issue?

[deivid-rodriguez]

I prefer a new ticket referencing this one.

[eregon]

OK, #3926

[deivid-rodriguez]

Thanks, I also edited the title of this ticket to reflect what we fixed in the PR that closed this.