[ruby-core:93000] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path

[eregontp@gmail.com]

Issue #15903 has been updated by Eregon (Benoit Daloze).

Assignee changed from Eregon (Benoit Daloze) to matz (Yukihiro Matsumoto)

mame (Yusuke Endoh) wrote:
> However, we can't be too careful to add anything to `Kernel` nowadays.

I propose only as a class method, not an instance method, so I think there is literally no chance for conflicts. What's your concern?

> At least, I don't want to do that until we receive an actual request to make the method available in production.

We very rarely receive this, e.g., even for RubyVM::InstructionSequence which is now used in production (bootsnap).
I think it is not a good criteria, it's just too easy to use `RubyVM` in user code.

I understand we should have an actual use-case, but we already have since the feature was introduced.
It would be useful when wanting to have more control over loading files (e.g., I guess this could be useful in RubyGems), and potentially bootsnap as @byroot just said above.

> Currently, I have no reason to move it to `Kernel`, except module design consistency.

I think that's a good enough reason on its own.
`RubyVM` shouldn't become a random collections of classes & methods of which part of it are MRI-specific and part not, part stable and part not.
That's just so messy, so I'd like to fix that.
This issue is a trivial fix for I think an obvious case that does not belong under `RubyVM`.

> This is just my opinion.  It is all right if matz accepted this.

OK, I'll assign to him and add to the developer meeting's agenda.

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

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* 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/