Issue #15903 has been updated by byroot (Jean Boussier).


This is kinda tengential, so sorry if it's shifting the discussion. But if `resolve_feature_path` is to be made a first class public API, I wonder if it could be the occasion to make `Kernel#require` invoke `Kernel#resolve_feature_path` under the hood.

The reasoning is similar to [#11140] which made `Kernel#autoload` invoke `Kernel#require` and allowed tools like bootscale / bootsnap.

If the feature resolution logic was swappable it could make these tools much simpler, and open the door to avoiding $LOAD_PATH entirely. 


----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78367

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: Eregon (Benoit Daloze)
* Target version: 2.7
----------------------------------------
RubyVM contains mostly MRI-specific features but `resolve_feature_path` is clearly not MRI-specific.

So I propose to move it as a class method of `Kernel`.
I think this makes sense given the related `load` and `require` are defined in `Kernel` too.

Moreover, moving this method outside `RubyVM` is *necessary* for other Ruby implementations to implement it, and keep the clean separation that `RubyVM` is only defined on MRI (see #15752).

So, can I move `RubyVM.resolve_feature_path` to `Kernel.resolve_feature_path`?

Do we need to keep the method on RubyVM (and deprecate it), or can we just remove it since anyway API under RubyVM is not stable?

cc @mame



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