"Calling DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)' has been deprecated. Please call DidYouMean.correct_error(error_name, spell_checker)' instead."

[dentarg]

Describe the problem as clearly as you can

Looks like any lockfile with a Bundler version below 2.3.3 (and recent enough to include the offending code) will print the

Calling `DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)' has been deprecated. Please call `DidYouMean.correct_error(error_name, spell_checker)' instead.

warning when using Ruby 3.1 that ships with did_you_mean 1.6.1 that has deprecated access to DidYouMean::SPELL_CHECEKRS

I see this has been addressed by 1074771 but is there anything that can be done for old versions? I guess this is a side-effect of the automatic bundler version switching introduced in Bundler 2.3.

Maybe Bundler should always print something when auto-switching? Then it would be a bit more obvious why you see the deprecation message (and it is probably useful in other scenarios too).

Post steps to reproduce the problem

$ bundler -v
Bundler version 2.3.3

$ bundle init
Writing new Gemfile to /Users/dentarg/test/Gemfile

$ gem install bundler -v 2.2.33
Fetching bundler-2.2.33.gem
Successfully installed bundler-2.2.33
1 gem installed

$ cat Gemfile.lock
GEM
  remote: https://rubygems.org/
  specs:

PLATFORMS
  x86_64-darwin-19

DEPENDENCIES

BUNDLED WITH
   2.2.33

$ bundle install
Bundler 2.3.3 is running, but your lockfile was generated with 2.2.33. Installing Bundler 2.2.33 and restarting using that version.
Calling `DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)' has been deprecated. Please call `DidYouMean.correct_error(error_name, spell_checker)' instead.
The Gemfile specifies no dependencies
Bundle complete! 0 Gemfile dependencies, 1 gem now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

$ bundle list
Calling `DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)' has been deprecated. Please call `DidYouMean.correct_error(error_name, spell_checker)' instead.
No gems in the Gemfile

What were you expecting to happen?

No warning printed.

What actually happened?

Warning printed.

[deivid-rodriguez]

Hi!

Yeah, this was very unfortunate and I can see how it's annoying. The warning came up very close to the release, and we only had time to fix it, but not to become aware of how the feature of auto-installing the locked version and auto-switching to it on the fly would play with it.

If I understood your suggestion properly, it is that we always log something when bundler auto-switches (by auto-switching I mean activating the locked version of bundler if available instead of the latest version). I think that might be too verbose and annoying. It would force users to upgrade all their apps to be locked to the latest bundler version installed in their system if they want to avoid this message being printed on every bundler invocation. It sounds like too much.

Something I would've done if I had realized about this issue beforehand (I even considered it without knowing about this issue) is to limit this new feature to lockfiles generated with bundler versions >= 2.3, so that existing lockfiles get no behavioral change at all. I guess it won't have the desired effect now since ruby 3.1 is already out, but might be a good idea anyways? Not %100 sure.

It's also really unfortunate to have introduced #5221 with the release, so it makes the recommended way out of this not work. Anyways, the fix for that will be released very soon.

[hsbt]

/cc @yuki24

[deivid-rodriguez]

I'll be releasing bundler 2.3.4 now, so that at least the easy way out of this warning, i.e., running bundle update --bundler, works again.

I'm also considering limiting auto-switching to Gemfile.lock files locked to bundler >= 2.3 but at this point I think it's not worth it. Ruby 3.1 including did_you_mean 1.6.1 and bundler 2.3.3 is already out. So this warning will appear by default on Gemfile.lock files locked to older bundler versions. So to fix the warning, user action is required anyways.

[deivid-rodriguez]

Also, just to make sure there's an easy way out of this posted here, running

bundle _2.3.3_ update --bundler

should update your lockfile to use bundler 2.3.3 and get you out of this warning. Plain bundle update --bundler does not work due to a regression that will be fixed by bundler 2.3.4.

EDIT: I released bundler 2.3.4, so if you install that (gem install bundler), now bundle update --bundler should be enough to get rid of the warning. In future bundler versions (hopefully the next one), you won't need a previous gem install bundler step to update the version of bundler your application uses to the latest version.

[dentarg]

If I understood your suggestion properly, it is that we always log something when bundler auto-switches (by auto-switching I mean activating the locked version of bundler if available instead of the latest version). I think that might be too verbose and annoying. It would force users to upgrade all their apps to be locked to the latest bundler version installed in their system if they want to avoid this message being printed on every bundler invocation. It sounds like too much.

Sure, I get it could be too much.

Is it possible to run Bundler in some sort of debug/verbose mode? So one can follow what's happening.

Even bundler -v will say Bundler version 2.2.33 when you are in a folder where there's a lockfile with BUNDLED WITH set to 2.2.33. But if you aren't in such a folder, but have both Bundler 2.3.3 and 2.2.33 installed, bundler -v will say Bundler version 2.3.3. I suspect in the lockfile case, Bundler auto-switched before printing the version string, despite Bundler 2.3.3 being invoked?

[deivid-rodriguez]

Even bundler -v will say Bundler version 2.2.33 when you are in a folder where there's a lockfile with BUNDLED WITH set to 2.2.33. But if you aren't in such a folder, but have both Bundler 2.3.3 and 2.2.33 installed, bundler -v will say Bundler version 2.3.3. I suspect in the lockfile case, Bundler auto-switched before printing the version string, despite Bundler 2.3.3 being invoked?

Yes, this is the expected behavior. If you're in an application context, RubyGems chooses the locked version of Bundler in the Gemfile.lock file when you run bundle (if present). If you are outside of an application context, RubyGems chooses the latest version of Bundler available in the system. This has been a feature of RubyGems for 4 years now. Note that in an application context, Bundler 2.3.3 is not invoked at all in this case. RubyGems activates the 2.2.33 version directly. That's why bundle -v prints 2.2.33 correctly.

What we have changed now, is that even if the exact version of Bundler is not present in the system before running bundle , and thus RubyGems falls back to choosing the latest version, bundle install will install the locked version first, and then restart itself, so that RubyGems now has the opportunity to choose the locked version directly.

Hope this makes sense.

Is it possible to run Bundler in some sort of debug/verbose mode? So one can follow what's happening.

We have a --verbose flag, that in particular logs something like

Running bundle install --verbose with bundler 2.3.3

right after start. However, Bundler keeps a list of "parseable commands" (for example, --version) that skip this message at all.

[deivid-rodriguez]

Not sure if skipping this message in --verbose mode is a good idea. To be honest, I don't really consider the output of any command "parsable", let alone if --verbose is given. But it's how it works now 🤷.

[yuki24]

Apologies for the trouble this has caused. Is there anything I can do to mitigate the impact of the deprecation message?

[zchrb]

I'm still getting the warning after installing bundler 2.3.4 and running bundle update --bundler as suggested by @deivid-rodriguez
Edit: I'm getting the warning when I run rails -v

[dmartinatdu]

Similarly, I've followed directions to install bundler 2.3.4 and run bundle update --bundler, still seeing the error message.

[robertwoolley99]

..At the risk of sound AOL-like from 1994 - me too. Sorry.

[mensfeld]

@dmartinatdu you may be seeing it because despite installing newer version, old one is used to install your dependencies.

[robertwoolley99]

@mensfeld I've removed all versions of bundler except 2.3.4 - still getting the warning. Viz:

gem list|grep bundl
bundler (2.3.4)
bundler-unload (1.0.2)
rubygems-bundler (1.4.5)

rails -v
Calling `DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)' has been deprecated. Please call `DidYouMean.correct_error(error_name, spell_checker)' instead.
Rails 6.1.4.4

[mensfeld]

@robertwoolley99 what about bundler --version in the project root dir?

[robertwoolley99]

@mensfeld - 2.3.4 :

Roberts-MacBook-Pro:dockerisedsmoothflowcore ttrjw$ bundler --version
Bundler version 2.3.4

[mensfeld]

@robertwoolley99 no idea 🤷‍♂️ the last thing that comes to my mind, is to manually edit the end of Gemfile.lock to indicate the 2.3.4 as the bundler version, then to reload the shell (close the console and open it again).

[nolantait]

Quick fix for those trying to get commands working as outlined here:

RUBYOPT='--disable-did_you_mean' rails -v

Or whatever your command is. You can export it like:

export RUBYOPT='--disable-did_you_mean'

Then I can run rails -v without putting RUBYOPT before and it will work.

[yuki24]

Are you all running Ruby 3.1? If not, uninstalling the latest version of did_you_mean also should fix it.

$ gem i did_you_mean -v=1.5.0
$ gem uni did_you_mean -v=1.6.1

[jhibbeard89]

@yuki24 Amazing thank you that worked perfectly :)

[deivid-rodriguez]

Sorry for not being active the last few days, I'm moving home :)

Just pointing out that people still getting this warning with latest bundler is probably due to Rails using thor internally. You can also point to this PR in your Gemfile and it should fix the rails -v warnings.

@yuki24 Thanks for your attentiveness, I think it's fine. This was just an unlucky combination, and it should get better with time :)

[eregon]

Here are some ideas to improve the warning in did_you_mean so it's not shown by default since it's a deprecation warning: ruby/did_you_mean#171

[robertwoolley99]

Is this more of a Rails problem? If so, one for 7.0.1...

[deivid-rodriguez]

We won't be making any changes inside Bundler and/or RubyGems to address this, so I'll close this.

Please make sure your application runs a Bundler version where this is fixed, and you should be ok.

[deivid-rodriguez]

What's the result of bundle -v and bundle info thor?

[xiehui999]

+1

[Alireza12120]

چرا زمان نصب متاسپلویت ارور میدهدGem::Ext::BuildError: ERROR: Failed to build gem native extension؟

[sonm-usui]

for me, I changed the ruby version from 2.7.0 to 3.2.0 and it works for me

[synth]

#5234 (comment)

this tipped me to updating thor: bundle update thor - going from 1.1.0 to 1.3.0 cleared this for me.