Issue #16427 has been updated by 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.

----------------------------------------
Bug #16427: Revert did_you_mean promotion to default gem.
https://bugs.ruby-lang.org/issues/16427#change-83232

* Author: vo.x (Vit Ondruch)
* Status: Rejected
* Priority: Normal
* 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
----------------------------------------
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.

[1]: https://github.com/ruby/ruby/commit/0fef526606c72e7d2a3c83aebd9204da34016d96



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>