From: jaruga@...
Date: 2021-08-11T16:01:38+00:00
Subject: [ruby-core:104884] [Ruby master Bug#18066] Load did_you_mean/error_highlight even with --disable-gems

Issue #18066 has been updated by jaruga (Jun Aruga).


@vo.x 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".


----------------------------------------
Bug #18066: Load did_you_mean/error_highlight even with --disable-gems
https://bugs.ruby-lang.org/issues/18066#change-93243

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-linux]
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
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:

~~~ruby
    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)



-- 
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>