* [ruby-core:92986] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
@ 2019-06-05 20:13 ` eregontp
2019-06-05 20:17 ` [ruby-core:92987] " eregontp
` (13 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-06-05 20:13 UTC (permalink / raw
To: ruby-core
Issue #15903 has been reported by Eregon (Benoit Daloze).
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee:
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:92987] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
2019-06-05 20:13 ` [ruby-core:92986] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path eregontp
@ 2019-06-05 20:17 ` eregontp
2019-06-05 22:51 ` [ruby-core:92989] " jean.boussier
` (12 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-06-05 20:17 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by Eregon (Benoit Daloze).
Assignee set to Eregon (Benoit Daloze)
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78365
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:92989] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
2019-06-05 20:13 ` [ruby-core:92986] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path eregontp
2019-06-05 20:17 ` [ruby-core:92987] " eregontp
@ 2019-06-05 22:51 ` jean.boussier
2019-06-05 23:11 ` [ruby-core:92991] " mame
` (11 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: jean.boussier @ 2019-06-05 22:51 UTC (permalink / raw
To: ruby-core
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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:92991] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (2 preceding siblings ...)
2019-06-05 22:51 ` [ruby-core:92989] " jean.boussier
@ 2019-06-05 23:11 ` mame
2019-06-06 9:17 ` [ruby-core:93000] " eregontp
` (10 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: mame @ 2019-06-05 23:11 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by mame (Yusuke Endoh).
(I'm an author of `RubyVM.resolve_feature_path`.)
Sorry but I'm not so positive. From perspective of module design, I agree that `Kernel` module looks the best place to add the method. However, we can't be too careful to add anything to `Kernel` nowadays. At least, I don't want to do that until we receive an actual request to make the method available in production. Currently, I have no reason to move it to `Kernel`, except module design consistency.
This is just my opinion. It is all right if matz accepted this.
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78369
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93000] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (3 preceding siblings ...)
2019-06-05 23:11 ` [ruby-core:92991] " mame
@ 2019-06-06 9:17 ` eregontp
2019-06-06 9:18 ` [ruby-core:93001] " eregontp
` (9 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-06-06 9:17 UTC (permalink / raw
To: ruby-core
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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93001] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (4 preceding siblings ...)
2019-06-06 9:17 ` [ruby-core:93000] " eregontp
@ 2019-06-06 9:18 ` eregontp
2019-06-06 9:25 ` [ruby-core:93002] " eregontp
` (8 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-06-06 9:18 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by Eregon (Benoit Daloze).
byroot (Jean Boussier) wrote:
> 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.
Could you file a separate feature request and show or explain how bootsnap would use it?
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78378
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93002] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (5 preceding siblings ...)
2019-06-06 9:18 ` [ruby-core:93001] " eregontp
@ 2019-06-06 9:25 ` eregontp
2019-06-06 9:59 ` [ruby-core:93007] " mame
` (7 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-06-06 9:25 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by Eregon (Benoit Daloze).
deep-cover might be interested by this too, cc @marcandre
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78379
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93007] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (6 preceding siblings ...)
2019-06-06 9:25 ` [ruby-core:93002] " eregontp
@ 2019-06-06 9:59 ` mame
2019-06-13 8:24 ` [ruby-core:93097] " nobu
` (6 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: mame @ 2019-06-06 9:59 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by mame (Yusuke Endoh).
Eregon (Benoit Daloze) wrote:
> 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
Oh sorry I missed the point. Fair enough. I'll ask matz's opinion at the next meeting.
> > 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.
Let's try to remove it and see how many people are killed. (Joke)
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78383
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93097] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (7 preceding siblings ...)
2019-06-06 9:59 ` [ruby-core:93007] " mame
@ 2019-06-13 8:24 ` nobu
2019-06-13 9:33 ` [ruby-core:93101] " eregontp
` (5 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: nobu @ 2019-06-13 8:24 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by nobu (Nobuyoshi Nakada).
How about `$LOAD_PATH.resolve_feature_path`?
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78519
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93101] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (8 preceding siblings ...)
2019-06-13 8:24 ` [ruby-core:93097] " nobu
@ 2019-06-13 9:33 ` eregontp
2019-06-14 2:51 ` [ruby-core:93123] " mame
` (4 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-06-13 9:33 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by Eregon (Benoit Daloze).
nobu (Nobuyoshi Nakada) wrote:
> How about `$LOAD_PATH.resolve_feature_path`?
As a singleton method, and because `$LOAD_PATH` cannot be re-assigned?
It's a fun idea, although I suspect this will be very hard to find and document properly, so I think it's better on `Kernel` as a class method.
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78524
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93123] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (9 preceding siblings ...)
2019-06-13 9:33 ` [ruby-core:93101] " eregontp
@ 2019-06-14 2:51 ` mame
2019-06-14 21:45 ` [ruby-core:93148] " eregontp
` (3 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: mame @ 2019-06-14 2:51 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by mame (Yusuke Endoh).
This ticket was discussed at yesterday dev meeting. Currently there is no singleton method to `Kernel`, so some people were reluctant. Nobu counterproposed `$LOAD_PATH` as above, and matz said he waits for eregon's response to the counterproposal.
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78552
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93148] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (10 preceding siblings ...)
2019-06-14 2:51 ` [ruby-core:93123] " mame
@ 2019-06-14 21:45 ` eregontp
2019-07-11 4:53 ` [ruby-core:93660] [Ruby master " matz
` (2 subsequent siblings)
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-06-14 21:45 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by Eregon (Benoit Daloze).
Thanks for discussing the issue at the meeting.
I think having singleton-only methods on `Kernel` would be OK, and probably most of us agree having the instance method is not warranted for a rarely-used method.
`Kernel` makes sense to me, because it's where `require` and `load` are defined, and `resolve_feature_path` is a subset of those methods.
My main concern with `$LOAD_PATH` is documentation (e.g., where would it be listed on https://docs.ruby-lang.org/, there is no class, `globals.rdoc` doesn't seem right) and discoverability (hard to find it when searching for it), but otherwise it sounds fine.
Another concern with defining it on `$LOAD_PATH` is `resolve_feature_path` does not depend only on `$LOAD_PATH` but also on other values such as `Dir.pwd`, and maybe other things if the feature lookup changes behavior in the future.
Dear @matz, could you decide between `Kernel` and `$LOAD_PATH`?
I would be happy with either, and I believe that would be much better than `RubyVM` (as explained in the description).
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-78576
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93660] [Ruby master Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (11 preceding siblings ...)
2019-06-14 21:45 ` [ruby-core:93148] " eregontp
@ 2019-07-11 4:53 ` matz
2019-07-13 10:37 ` [ruby-core:93740] " eregontp
2019-07-13 13:37 ` [ruby-core:93741] " eregontp
14 siblings, 0 replies; 15+ messages in thread
From: matz @ 2019-07-11 4:53 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by matz (Yukihiro Matsumoto).
I vote for `$LOAD_PATH.resolve_feature_path`. We need to improve the documentation as well.
Matz.
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-79271
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93740] [Ruby master Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (12 preceding siblings ...)
2019-07-11 4:53 ` [ruby-core:93660] [Ruby master " matz
@ 2019-07-13 10:37 ` eregontp
2019-07-13 13:37 ` [ruby-core:93741] " eregontp
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-07-13 10:37 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by Eregon (Benoit Daloze).
Thanks for the decision, and thanks to @nobu for already moving the method.
I noticed the documentation is still on RubyVM, I'll try to fix that.
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-79377
* Author: Eregon (Benoit Daloze)
* Status: Closed
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ruby-core:93741] [Ruby master Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
` (13 preceding siblings ...)
2019-07-13 10:37 ` [ruby-core:93740] " eregontp
@ 2019-07-13 13:37 ` eregontp
14 siblings, 0 replies; 15+ messages in thread
From: eregontp @ 2019-07-13 13:37 UTC (permalink / raw
To: ruby-core
Issue #15903 has been updated by Eregon (Benoit Daloze).
I documented the new method in [globals.rdoc](https://github.com/ruby/ruby/blob/master/doc/globals.rdoc) and added a NEWS entry.
----------------------------------------
Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
https://bugs.ruby-lang.org/issues/15903#change-79378
* Author: Eregon (Benoit Daloze)
* Status: Closed
* 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/
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-07-13 13:37 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <redmine.issue-15903.20190605201351@ruby-lang.org>
2019-06-05 20:13 ` [ruby-core:92986] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path eregontp
2019-06-05 20:17 ` [ruby-core:92987] " eregontp
2019-06-05 22:51 ` [ruby-core:92989] " jean.boussier
2019-06-05 23:11 ` [ruby-core:92991] " mame
2019-06-06 9:17 ` [ruby-core:93000] " eregontp
2019-06-06 9:18 ` [ruby-core:93001] " eregontp
2019-06-06 9:25 ` [ruby-core:93002] " eregontp
2019-06-06 9:59 ` [ruby-core:93007] " mame
2019-06-13 8:24 ` [ruby-core:93097] " nobu
2019-06-13 9:33 ` [ruby-core:93101] " eregontp
2019-06-14 2:51 ` [ruby-core:93123] " mame
2019-06-14 21:45 ` [ruby-core:93148] " eregontp
2019-07-11 4:53 ` [ruby-core:93660] [Ruby master " matz
2019-07-13 10:37 ` [ruby-core:93740] " eregontp
2019-07-13 13:37 ` [ruby-core:93741] " eregontp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).