Bug #20714: Handle optional dependencies in `bundled_gems.rb`

• Status: Assigned
• Assignee: hsbt (Hiroshi SHIBATA)
• Target version: -
• ruby -v: 3.3.5
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[Earlopain (A S)]

I've encountered a few places around bundled gems where the library doesn't care if the gem is available, but will still provide some functionallity if it is.

The way to accomplish that right now seems to be by setting $VERBOSE = nil and resetting it later again to not bother the user with the warning about the gem. However, this has the effect of silencing the warning about other gems as well, that may not be prepared about the bundling.

From ruby/reline for example: https://github.com/ruby/reline/blob/c90f08f7e308d2f1cdd7cfaf9939fe45ce546fd2/lib/reline/terminfo.rb#L1-L15
Or the logging gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784/lib/logging.rb#L9-L15

I propose to simply delay the warning to the next require.

GitHub PR at https://github.com/ruby/ruby/pull/11545

[Earlopain (A S)]

• Description updated (diff)

[Eregon (Benoit Daloze)]

One potential problem with setting $VERBOSE to nil is that's not thread-safe, and so might hide valid warnings from other threads requiring around the same time.
Maybe it should be some explicit method in Gem or so to suppress that warning, or a keyword argument like require "foo", optional: true.

[Eregon (Benoit Daloze)]

The problem is any new API would be rather cumbersome to use (in a way that still works on older Rubies), so probably this fix is good as a quick measure.

I think it would be good to think about a longer-term solution too though.

[Earlopain (A S)]

Thanks for you reply, I was about to write something similar about the older rubies.

At first I was writing about how I don't think a new api is really necessary since the compatibility code can simply be dropped once required_ruby_version is at or above the ruby version that would error but I don't think that is entirely true. For example, on ruby 3.4 the following script produces this output:

begin
  require "webrick"
rescue LoadError
end

if defined?(Webrick)
  puts "Do some things"
end

# test.rb:2: warning: webrick was loaded from the standard library, but is not part of the default gems starting from Ruby 3.0.0.
# You can add webrick to your Gemfile or gemspec to silence this warning.

So even though webrick is gone since Ruby 3.0, I'd still have to do some trickery to optionally enhance it without triggering the warning.

I see two solutions:

• require "foo", optional: true like you suggested
• Drop warnings when ruby would throw an error here. When the require will raise, it doesn't need to warn. This is how I already imagined it works. I guess it doesn't for visibility?

[Eregon (Benoit Daloze)]

Maybe a good solution is to make $VERBOSE thread-local or fiber-local at some point, then at least this concern and related ones would be solved once and for all.

[deivid (David Rodríguez)]

Drop warnings when ruby would throw an error here. When the require will raise, it doesn't need to warn. This is how I already imagined it works. I guess it doesn't for visibility?

I think this is the best solution. The warning is also misleading if the require fails because it suggests that the require succeeded ("webrick was loaded from...").

Is it as simple as https://github.com/ruby/ruby/pull/11550?

[Earlopain (A S)]

deivid (David Rodríguez) wrote in #note-6:

Is it as simple as https://github.com/ruby/ruby/pull/11550?

I had something a little different in mind (trim SINCE) but I think that is a nice solution. The PR looks reasonable to me.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to hsbt (Hiroshi SHIBATA)

[hsbt (Hiroshi SHIBATA)]

• Related to Feature #20309: Bundled gems for Ruby 3.5 added