Bug #18066
closedLoad did_you_mean/error_highlight even with --disable-gems
Description
I guess that did_you_mean was not possible to load without RubyGems, when it used to be bundled gem. Since it is default gem, therefore part of StdLib and always available on load path, it should not be related to --disable-gems anymore.
IOW ruby.c contains this code:
if (opt->features.set & FEATURE_BIT(gems)) {
rb_define_module("Gem");
if (opt->features.set & FEATURE_BIT(error_highlight)) {
rb_define_module("ErrorHighlight");
}
if (opt->features.set & FEATURE_BIT(did_you_mean)) {
rb_define_module("DidYouMean");
}
}
while it should look like:
if (opt->features.set & FEATURE_BIT(gems)) {
rb_define_module("Gem");
}
if (opt->features.set & FEATURE_BIT(error_highlight)) {
rb_define_module("ErrorHighlight");
}
if (opt->features.set & FEATURE_BIT(did_you_mean)) {
rb_define_module("DidYouMean");
}
(I have not checked error_highlight, but I assume it behaves similarly to did_you_mean)
Updated by vo.x (Vit Ondruch) about 3 years ago
However, I am not sure what is the impact in case Ruby can be build with --disable-gems
configuration option (if that is possible).
Updated by vo.x (Vit Ondruch) about 3 years ago
- Subject changed from Load did_you_mean eve/error_highlight even with --disable-gems to Load did_you_mean/error_highlight even with --disable-gems
Updated by jeremyevans0 (Jeremy Evans) about 3 years ago
I think this change makes sense. It requires quite a few test changes, though. I submitted a pull request to implement it: https://github.com/ruby/ruby/pull/4729
Updated by duerst (Martin Dürst) about 3 years ago
I'm not sure how strongly this is related (and I'll create a new issue if necessary), but when I use a very simple script such as ruby -e 'puts 3+4'
, I get the following output:
`RubyGems' were not loaded.
`error_highlight' was not loaded.
`did_you_mean' was not loaded.
7
I think this is total overkill. Don't get me wrong: I'm fine (in this specific case) with RubyGems not being loaded (because no Gems are needed). I'm also fine with error_highlight and did_you_mean not being loaded (because they are not needed as long as my script has no errors). But it's total overkill that I'm told about this with 3 lines when all I want is to run a tiny script.
If this is a transitory state, then please ignore this complaint.
(ruby -v: ruby 3.1.0dev (2021-08-10T10:08:38Z master 28d03ee776) [x86_64-linux] on WSL2 on Win10)
Updated by jaruga (Jun Aruga) about 3 years ago
I'm not sure how strongly this is related (and I'll create a new issue if necessary), but when I use a very simple script such as ruby -e 'puts 3+4', I get the following output:
...
If this is a transitory state, then please ignore this complaint.(ruby -v: ruby 3.1.0dev (2021-08-10T10:08:38Z master 28d03ee776) [x86_64-linux] on WSL2 on Win10)
I tried to reproduce what you did on the master 28d03ee776 . But in my case, I used Fedora 34, as I don't have Windows. And the result looks ok on my environment.
$ cat /etc/fedora-release
Fedora release 34 (Thirty Four)
$ ~/local/ruby-28d03ee776/bin/ruby -v
ruby 3.1.0dev (2021-08-10T10:08:38Z master 28d03ee776) [x86_64-linux]
$ ~/local/ruby-28d03ee776/bin/ruby -e 'puts 3+4'
7
Updated by vo.x (Vit Ondruch) about 3 years ago
duerst (Martin Dürst) wrote in #note-4:
I'm not sure how strongly this is related (and I'll create a new issue if necessary), but when I use a very simple script such as
ruby -e 'puts 3+4'
, I get the following output:`RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. 7
Under what conditions you see these reports? This 1 is the place where those comes from, but you also need to have the relevant files removed from StdLib.
Updated by jaruga (Jun Aruga) about 3 years ago
@vo.x (Vit Ondruch) I would just share how the motivation of some maintainers look like to fix this kind of issue, as I chat with some maintainers on Slack today.
I understand that gems moving from bundled gem to default gem as StdLib tend to depend on RubyGems at an early time. I think your request comes from the fact that the "ruby" RPM package including StdLib has not depended on the "rubygems" sub RPM package on Fedora. And I see that the motivation is that we want to install only what we need, and good to reduce the installed files size.
Seeing Debian and Ubuntu ruby packages, the "ruby" deb package depends on "ruby-rubygems" deb package. I am curious about the situation of the "ruby" package on other Linux/UNIX platforms such as Arch, Gentoo, FreeBSD.
https://packages.debian.org/experimental/ruby
https://packages.ubuntu.com/impish/ruby
When chatting today, I see some maintainers were less motivated. Because historically in the age of Ruby 1.8, we installed RubyGems in addition. But nowadays splitting Ruby from RubyGems is not really a supported use case. It's a Linux, BSD distribution's ruby package specific use case. So, the way to make it possible nowadays is that some motivated people (Thanks Jeremy this time!) will send a PR, or Linux/*BSD packagers will rethink adding "rubygems" as a required dependency of "ruby" like Debian/Ubuntu. So, I think this kind of task is not "must" but "nice to have".
Updated by vo.x (Vit Ondruch) about 3 years ago
Just for the context, this issue was triggered when looking at 1. And as long as there is ruby --disable-gems
as well as ./configure --disable-rubygems
, I believe that it is correct to fix this.
Updated by xtkoba (Tee KOBAYASHI) about 3 years ago
jaruga (Jun Aruga) wrote in #note-7:
Seeing Debian and Ubuntu ruby packages, the "ruby" deb package depends on "ruby-rubygems" deb package. I am curious about the situation of the "ruby" package on other Linux/UNIX platforms such as Arch, Gentoo, FreeBSD.
Both Arch and Gentoo require ruby to be installed together with rubygems:
https://archlinux.org/packages/extra/x86_64/ruby/
https://packages.gentoo.org/packages/dev-lang/ruby/dependencies
Updated by mame (Yusuke Endoh) almost 3 years ago
- Status changed from Open to Rejected
We discussed this ticket at the dev-meeting, and @matz (Yukihiro Matsumoto) rejected this.
Now the --disable-gems
option is just for debugging, not for casual users. We, the core developers, mainly use the option to investigate the startup overhead of the interpreter core, so typically we want to disable did_you_mean and error_highglight when we use --disable-gems
. If we really want to enable did_you_mean under --disable-gems
, we can use --disable-gems -rdid_you_mean
.