Bug #16427: Revert did_you_mean promotion to default gem.

• Status: Rejected
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -
• ruby -v: ruby 2.7.0dev (2019-12-10 master af11efd377) [x86_64-linux]
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN

[vo.x (Vit Ondruch)]

One of the points made in #16363 was:

so we can always reliably require it whenever we want to.

That is not true anymore, because did_you_mean is always required when RubyGems are enabled since 1:

$ ruby -e 'puts $LOADED_FEATURES' | grep did

Removing all traces of did_you_mean from my system only results in:

$ ruby -e 'puts $LOADED_FEATURES' | grep did
Traceback (most recent call last):
	2: from <internal:gem_prelude>:2:in `<internal:gem_prelude>'
	1: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require'
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- did_you_mean (LoadError)

just confirming what I said above.

IMO, did_you_mean gem might be useful for development, but should not be required for runtime at all. On one hand there are taken steps to improve Ruby speed, but this is going contrary to that goal.

[vo.x (Vit Ondruch)]

• Related to Feature #16363: Promote did_you_mean to default gem added

[rbjl (Jan Lelis)]

I want to make point for the default gem promotion.

One of Ruby's goal is to be very appealing to developers. did_you_mean is very helpful in this regard. As are well written error messages. Or source_locations of Ruby methods. Or a well usable REPL. You are right about the perfomance implication, but - of course, this is a matter of taste - the improved experience for developers can outweigh this.

One thing about the "auto-requiring" of did_you_mean -> I think this also a reason for having did_you_mean included as a default gem. It was some kind of inconsistent that did_you_mean would be loaded implicitly, but can be removed. Now being a default gem, this behavior is not problematic anymore.

[mame (Yusuke Endoh)]

• Status changed from Open to Rejected

It does not make sense at all.

In Ruby 2.6, did_you_mean was a bundled gem, which may be uninstalled by a user. As it is not always able to require, gem_prelude.rb did require "did_you_mean" rescue LoadError.
In Ruby 2.7, did_you_mean is a default gem, which cannot be uninstalled by a user. So "we can always reliably require it whenever we want to". rescue LoadError is no longer needed, and removed at 0fef526606c72e7d2a3c83aebd9204da34016d96.

Of course, if you delete "lib/did_you_mean.rb", ruby does not work. But it's just like saying that "ruby cannot start when I remove lib/rubygems.rb".

[vo.x (Vit Ondruch)]

• Assignee set to nobu (Nobuyoshi Nakada)

mame (Yusuke Endoh) wrote:

But it's just like saying that "ruby cannot start when I remove lib/rubygems.rb".

Speaking of which is problematic by itself. But the difference is that 99% of Ruby applications needs RubyGems for their runtime, while 99% of Ruby applications does not need did_you_mean. Audience of this site might be biased, because they are Ruby developers, who use IRB, Rake, generate new Rails apps and runs other Ruby applications during development and they find the output of did_you_mean helpful. But in production environment

1. 99 % of applications run in non-interactive mode.
2. These applications are presumably well tested and did_you_mean provides no service at all.

But all these applications have to pay for longer startup time, higher memory and disk consumption. All these are not negligible in the age of cloud. I am pretty sure there is also performance hit during exception handling.

Also, you perceive Ruby as monolith distributed in via tarball where everything is available. On Fedora (and RHEL subsequently), rubygem-did_you_mean was always installed by default with Ruby, but there was option to easily exclude it from installation for all the reasons mentioned above. SInce, this change, it won't be easily possible. I am really considering reverting the change for Fedora.

[rbjl (Jan Lelis)]

But all these applications have to pay for longer startup time, higher memory and disk consumption. All these are not negligible in the age of cloud. I am pretty sure there is also performance hit during exception handling.

Then, a good configuration for the cloud could be this?

$ ruby --disable-did_you_mean -e "p defined? DidYouMean" # => nil

[vo.x (Vit Ondruch)]

rbjl (Jan Lelis) wrote:

Then, a good configuration for the cloud could be this?

$ ruby --disable-did_you_mean -e "p defined? DidYouMean" # => nil

It should probably be $ RUBYOPT=--disable-did_you_mean ruby -e "p defined? DidYouMean" # => nil because env variables are typically easier to configure without touching any scripts. Nevertheless it does not address the "disk consumption" concern. I also previously forgot to mention possible increased network bandwidth required to build and distribute the cloud image.

[vo.x (Vit Ondruch)]

• Related to Feature #16431: Optionally load did_you_mean (and RubyGems) added

[shevegen (Robert A. Heiler)]

I think the issue is that the filing is about reverting the promotion to
default gems, which is different to the use case of making it (or what a
ruby user wants to use) more flexible.

The ideal scenario would be to have a fully customizable ruby, at all
times. Something like, if we compare MRI ruby and mruby, and be able
to include any gems as-is no matter which "base ruby" is used, like
LEGO building blocks. Like in the old discussion for making stdlib
gemified.

[...] Nevertheless it does not address the "disk consumption"
concern. I also previously forgot to mention possible increased
network bandwidth required to build and distribute the cloud image.

See - you may have valid reasons, and I agree on the part that ruby
should ideally be as customizable as possible at all times. But others
have valid reasons too, and in this context I agree with the promotion
to a default gem. Granted I am biased because I like the did-you-mean
gem, but I also don't think that the reasoning should be to NOT
promote it because of your use case being more important than other
use cases, such as being able to use the did-you-mean gem by default.

It's a bit similar to warnings or not showing warnings - they can be
annoying, but they can also be helpful, so you have a situation that
is somewhat orthogonal. The proper long term solution would be to
allow for the desired flexibility.

MRI ruby targets "regular" ruby users and their use cases may show
a range of different "wants and needs". Note that I do not necessarily
have an opposite opinion to your issue request; I just don't think that
should be the primary line of reasoning. The ideal solution would be
to see that gem/bundler would allow for as much "customizability" as
possible.

[Eregon (Benoit Daloze)]

vo.x (Vit Ondruch) wrote:

Nevertheless it does not address the "disk consumption" concern. I also previously forgot to mention possible increased network bandwidth required to build and distribute the cloud image.

By how much does it increase disk/network usage compared to the rest of Ruby?
If it's just a couple percents it doesn't sound much to me, and the same could then be said of most of stdlib.

Default gems are the same as stdlib, so having ruby without did_you_mean in Fedora IMHO is just as bad as not having set when installing ruby on Fedora.