Fix deprecation messages for bundle install flags, the config should be --local as before

[eregon]

• Closes Deprecation messages recommending bundle config don't have the same effect as the old persisted flags #3916.
• Always show --local or --global for bundle config set commands as
  the default is global which can be not intuitive (Deprecation messages recommending bundle config don't have the same effect as the old persisted flags #3916).

Tasks:

• Describe the problem / feature
• Write tests
• Write code to solve the problem
• Get code review from coworkers / friends

I will abide by the code of conduct.

[deivid-rodriguez]

Looks good! Being explicit is a good step forward for now, and makes it easier to change the default in the future.

[eregon]

@deivid-rodriguez I think I addressed everything now, and I added a CHANGELOG entry, should be good to go, except that regeneration of bundle-config.1.txt (unless we're fine with it?).

[eregon]

FWIW I like bundle config --local path vendor/bundle better than bundle config set --local path vendor/bundle but given that seems deprecated for Bundler 3 I went with the Bundler 3 syntax and explicit set (which is another difference to git config).
(Specifically if we change the default to --local, bundle config path vendor/bundle sounds nicer than bundle config set path vendor/bundle to me)

[deivid-rodriguez]

@deivid-rodriguez I think I addressed everything now, and I added a CHANGELOG entry, should be good to go, except that regeneration of bundle-config.1.txt (unless we're fine with it?).

You can skip the changelog message since I plan to start generating the changelog automatically from merge PR titles and labels in the next version.

FWIW I like bundle config --local path vendor/bundle better than bundle config set --local path vendor/bundle but given that seems deprecated for Bundler 3 I went with the Bundler 3 syntax and explicit set (which is another difference to git config).
(Specifically if we change the default to --local, bundle config path vendor/bundle sounds nicer than bundle config set path vendor/bundle to me)

I'm also unsure about deprecating the old bundle config interface, that's why I delayed it until it can be better discussed, and the original reasons properly reviewed: rubygems/bundler#7475. But we're using the new interface internally in a consistent way at the moment, so let's keep doing it for the moment 👍.

[deivid-rodriguez]

Also, I think we can ignore the annoying txt diff for this PR, and try to get rid of txt files at all as you suggested.

[eregon]

You can skip the changelog message since I plan to start generating the changelog automatically from merge PR titles and labels in the next version.

Should I remove that change then?

I'm also unsure about deprecating the old bundle config interface, that's why I delayed it until it can be better discussed, and the original reasons properly reviewed: rubygems/bundler#7475. But we're using the new interface internally in a consistent way at the moment, so let's keep doing it for the moment .

Is there some good place to discuss that? I feel this deprecation is going to be rather annoying (and require verbose commands) for very little gains. The only conflict would be if one needs to set a key named list/get/set/unset but that seems extremely unlikely.

Also, I think we can ignore the annoying txt diff for this PR, and try to get rid of txt files at all as you suggested.

Will you make a PR or is there a plan for that then? 😃
I guess we should wait to merge this PR after that?

I think this PR should be merged for the next Bundler 2 release, it's quite bad if people configure globally when they do not intend to (can cause confusion, or an impression that the deprecation messages are just broken and due to that might be ignored more).

[deivid-rodriguez]

Should I remove that change then?

It will be overwritten unless the PR title matches the current wording exactly, so yeah I'd rather remove it!

Is there some good place to discuss that? I feel this deprecation is going to be rather annoying (and require verbose commands) for very little gains. The only conflict would be if one needs to set a key named list/get/set/unset but that seems extremely unlikely.

Feel free to open a new ticket, investigate why the new interface was added, and explain why you think the reasons for making it compulsory are wrong.

Will you make a PR or is there a plan for that then? 😃
I guess we should wait to merge this PR after that?

I like your idea, but it came up literally 1 hour ago, so I'm not sure when I (or anybody) will get to it. Better not to block this PR on that.

I think this PR should be merged for the next Bundler 2 release, it's quite bad if people configure globally when they do not intend to (can cause confusion, or an impression that the deprecation messages are just broken and due to that might be ignored more).

Sure, just be patient! :)

[eregon]

OK, CHANGELOG entry removed. I worked around and now the diff for bundle-config.1.txt should be minimal.
Ready to be merged :)

[deivid-rodriguez]

Thanks!