Issue #20714 has been updated by 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`. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109620 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by 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: ```rb 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? [here]: https://github.com/ruby/ruby/blob/294dad22d7ac5f307d567cff897507b9fd9d05e9/l... ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109622 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by 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? ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109624 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109635 * Author: Earlopain (A S) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by hsbt (Hiroshi SHIBATA). @deivid Thanks for sharing. My concern is [here](https://github.com/ruby/ruby/pull/11550#issuecomment-2376573020) I will consider what's better approach for us with https://github.com/ruby/ruby/pull/11550 and https://github.com/ruby/ruby/pull/11545 before 3.4.0-preview2. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109910 * Author: Earlopain (A S) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by Eregon (Benoit Daloze). https://github.com/ruby/ruby/pull/11550 seems a good solution to me. I think it is expected to only get the LoadError for `csv` on 3.4 and not also the warning. People seeing the LoadError for `csv` would intuitively add `csv` to their Gemfile, which is the same they would do to address the warning. For non-Bundler usages as far as I understand `require 'csv'` would still so that's unaffected. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109912 * Author: Earlopain (A S) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by Earlopain (A S). I see that https://github.com/ruby/ruby/pull/11550 was merged which is great but I'm confused about https://github.com/ruby/ruby/commit/ff3f61556fb62d12d57d017f4c54f1a8fd5208be because it basically reverts that PR. If a dependency is optional depends on each specific use and while this applies to fiddle through reline and how it uses it, other cases not from stdlib/bundled are ignored. I'm also not sure it the conditions are correct. For fiddle, it will never use `OPTIONAL` since the LoadError is truthy, and other gems always warn for the same reason. I don't see how this now behaves differently than before. Could you explain? ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109923 * Author: Earlopain (A S) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by deivid (David Rodríguez). I meant that I think in Ruby 3.4 (prior to my patch), the warning would also apply to non Bundler contexts that lead to a `LoadError`, where it would inform that `csv` may not always be present and may need an explicit install from RubyGems.org. But I have not tried this myself, just assumed it from reading the code, so maybe I misunderstood. By the way, I share @Earlopain's questions about the additional patch introduced after https://github.com/ruby/ruby/pull/11550. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109940 * Author: Earlopain (A S) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by Earlopain (A S). https://github.com/ruby/ruby/commit/3a9e48b9a4860022f43d8101c0f3249299437886 this seems better but I still question the rationale. I don't see the point in giving `fiddle` special treatment with `OPTIONAL`. What problem is this solving? All it does is supress the warning from `reline` (which is suppressed directly in the gem right now anyways) when `fiddle` is gone in 3.5 but all the other gems that are still do warn. It seems needlessly inconsistent. Again, if a gem is optional depends on how it is used. Don't give everyone else with `fiddle` the same treatment just because `reline` does it in a specific way. My opinion is that either all gems should warn indefinitely or none. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109967 * Author: Earlopain (A S) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by Earlopain (A S). I apologize for my tone, I will try to be more understanding. I am just a bit frustrated with the warnings in general, especially with the ones that were backported 3.3.5. I know it is already reverted but they do still happen now. It would have been nicer if you instead made your changes as a PR so that others could have given feedback instead of checking latest commits and writing about it here after. Anyways, let's see if others have an opinion. I'll just take it as it comes now. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109969 * Author: Earlopain (A S) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by hsbt (Hiroshi SHIBATA). I have no idea to correctly handling optional dependency now. I reverted related commit for Ruby 3.4 at https://github.com/ruby/ruby/commit/441069c093ab0d21efff1f0f3144fdf412f9f675. I'll try that targeted Ruby 3.5 or feature. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-110631 * Author: Earlopain (Earlopain _) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by Earlopain (Earlopain _). https://github.com/ruby/ruby/commit/8cd36a6dab170f4127c58c07b1a388dd3813fb7a removed the first batch of gems from the list of warnings. I agree with it and don't particularly care if these warn a few years after removal, as long as it stops at one point. The warning message is still confusing for future ruby versions though. The issue I see with your PR is that for one version, they will still warn regardless. So, for a somewhat specific example: * Some gem `x` requires `fidlde` and handles the potential `LoadError` * Gem `x` starts to warn on Ruby 3.4, but this gem is already equiped to handle it. The warning is unnecessary * Other gems loaded after `x` may also require `fiddle` but will not warn since the warning was already emitted * On Ruby 3.5, gem `x` works and doesn't emit a warning anymore * However, gems loaded after `x` will error if they failed to declare `fiddle` as their dependency I guess you could just rely on the multitude of different gemfiles people have and guess that there is someone without gem `x` to report the warning to the other gem author. But I'm unsure if that is a safe bet to make. I don't think you can properly handle it in `bundled_gems.rb` with what is currently available, the information about if a require should warn or not is simply not there. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-110636 * Author: Earlopain (Earlopain _) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by Eregon (Benoit Daloze). I think the trouble is on `require 'fiddle'` in 3.4, e.g. in reline, it would actually succeed (and return true): ```ruby source 'https://rubygems.org' gem 'reline' ``` ``` $ bundle install $ bundle exec ruby -ve 'require "reline"; p Fiddle' ruby 3.4.0preview2 (2024-10-07 master 32c733f57b) +PRISM [x86_64-linux] Fiddle ``` If we remove the `$VERBOSE` changes in lib/reline/terminfo.rb: ``` $ bundle exec ruby -e 'require "reline"; p Fiddle' /home/eregon/tmp/reline-gemfile/vendor/bundle/ruby/3.4.0+0/gems/reline-0.5.11/lib/reline.rb:9: warning: fiddle was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0. You can add fiddle to your Gemfile or gemspec to silence this warning. Fiddle ``` So I think https://github.com/ruby/ruby/pull/11550 wouldn't solve that. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-110642 * Author: Earlopain (Earlopain _) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by deivid (David Rodríguez). Oh, indeed. You're right. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-110644 * Author: Earlopain (Earlopain _) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/

Issue #20714 has been updated by deivid (David Rodríguez). @hsbt I tried my approach again, but (I think) without the defect of making users possibly miss the bundled gems warnings completely if they jump from one version that did not show warnings to a version where the bundled gem is already removed. This: https://github.com/ruby/ruby/pull/11550. However, as pointed out before, it does not remove the warnings while the gem has not yet been removed, so I'm not convinced it's worth introducing. @Earlopain's alternative seems a bit more appealing since it at least provides a way for users to get rid of the warnings without having to artificially add a gem that's not really required as a dependency. But overall, the `require ..., optional: true` feature idea seems like the best alternative to me. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-112064 * Author: Earlopain (Earlopain _) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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... Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784... I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/