Feature #4233: autoload Can't Require Gems

• Status: Closed
• Assignee: nahi (Hiroshi Nakamura)
• Target version: 2.6

[runpaint (Run Paint Run Run)]

=begin
Is it intentional that when used via autoload, require can't handle Gem names?

 run@desktop:~/mir/ruby$  →  ruby -e 'p require "nokogiri"'
 true
 run@desktop:~/mir/ruby$  →  ruby -e 'autoload(:N, "nokogiri"); p N'
 -e:1:in `<main>': cannot load such file -- nokogiri (LoadError)

=end

[naruse (Yui NARUSE)]

• Status changed from Open to Assigned
• Assignee set to nahi (Hiroshi Nakamura)
• Target version set to 2.0.0

[nahi (Hiroshi Nakamura)]

• Tracker changed from Bug to Feature

[mame (Yusuke Endoh)]

• Assignee changed from nahi (Hiroshi Nakamura) to drbrain (Eric Hodel)

Is this really a feature request? Looks a (low-priority?) bug to me.
drbrain, what do you think about this?

--
Yusuke Endoh [e-mail]

[drbrain (Eric Hodel)]

• Assignee changed from drbrain (Eric Hodel) to nahi (Hiroshi Nakamura)

=begin
If I'm reading load.c correctly, autoload_provided() uses rb_feature_provided() which checks $LOAD_PATH only. This will cause autoload to fail if the gem has not been activated yet.

If autoload's specification only allows autoloading from $LOAD_PATH this is not a bug. The documentation for Kernel#autoload does not say how the file will be loaded, but Module#autoload says:

Registers filename to be loaded (using Kernel::require) the first
time that module (which may be a String or a symbol) is accessed
in the namespace of mod.

Which implies it is a bug. Perhaps this documentation is wrong.

Since nahi is the autoload expert, I have assigned this back to him.

=end

[mame (Yusuke Endoh)]

• Target version changed from 2.0.0 to 2.6

Thank you drbrain for the explanation!
Recently, nahi is not so active. So, I'm sorry but I recognize this as a (bad) spec of 2.0.0.

--
Yusuke Endoh [e-mail]

[mame (Yusuke Endoh)]

• Status changed from Assigned to Closed

Seems this issue was fixed. Closing.