Bug #20920
openWhen loading a file, __FILE__ gets relative paths expanded only when they start with "./"
Description
$ cat foo.rb
puts __FILE__
$ ruby foo.rb
foo.rb
$ ruby ./foo.rb
./foo.rb
$ ruby -e 'load "foo.rb"'
foo.rb
$ ruby -e 'load "./foo.rb"'
/full/path/to/foo.rb
More than an issue, this is mainly a question. In principle, it seems more consistent to me to either expand or not expand, but this is not causing real issues for me. I just want to figure out what to do with one pending spec in Bundler (https://github.com/rubygems/rubygems/blob/cd65092deb3168759820c613ecbc54cd9e06d46f/bundler/spec/commands/exec_spec.rb#L1023-L1028).
Updated by deivid (David Rodríguez) 20 days ago
- Description updated (diff)
- ruby -v set to ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [arm64-darwin23]
Updated by Dan0042 (Daniel DeLorme) 12 days ago
It's interesting that this highlights the only case where load
searches in a different path than require
if path is absolute
load/require absolute path --> __FILE__ is absolute
elsif path starts with "." or ".."
load/require relative to pwd --> __FILE__ is expanded to absolute
else
load/require relative to each $LOAD_PATH --> __FILE__ is expanded to absolute
if above not found, load (but not require) relative to pwd --> __FILE__ is NOT expanded to absolute
end
Updated by vo.x (Vit Ondruch) 12 days ago
This is very related to #16978
And all this started with introduction of require_relative
and it is a mess since then. IMHO, the path expansion is evil. It prevents usage of symlinks, it is troublesome with modifications of $LOAD_PATH
, etc.
Updated by deivid (David Rodríguez) 8 days ago
For what it's worth, this is not currently causing any issues in Bundler/RubyGems that I know of, so I changed the pending spec to track current Ruby's behavior and move on. From my side, this can be closed, but of course if Ruby maintainers think that it's worth and possible to bring more consistency here, I fully support that too.