Feature #5421: -r option useless

• Status: Rejected
• Assignee: -
• Target version: -

[trans (Thomas Sawyer)]

Ran into a problem trying to require a plugin I had written while running a ruby scipt, e.g.

$ ruby -rmyplugin script.rb

It tells me "no such file" for myplugin. Turns out the problem is that the -r option uses internal require code and thus circumvents rubygems or any modified #require, so even though my RUBYOPT="-rubygems", it makes no difference. I've also been informed that RUBYOPT is applied after -r options, which makes for an additional problem. Apparently this so -T can ignore RUBYOPT? But if that's the only reason, then -T should be preparsed from ARGV b/c having -r options load first prevents augmentation and use of what RUBYOPT loads by -r. RUBYOPT is supposed to set the environment, but it isn't much of an environment if its not there when I run a ruby command.

I've marked this report as a feature b/c I'm sure someone would take issue if I did otherwise, but I personally see it as a bug b/c it makes -r useless in many cases.

[drbrain (Eric Hodel)]

• Status changed from Open to Rejected

=begin
ruby -r uses RubyGems now, you probably need to upgrade your ruby:

$ gem19 which nokogiri
/usr/local/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.0/lib/nokogiri.rb
$ ruby19 -rnokogiri -ve 'p Nokogiri'
ruby 1.9.3dev (2011-09-27 revision 33347) [x86_64-darwin11.1.0]
Nokogiri

$ ~/.multiruby/install/1.9.2-p290/bin/gem which nokogiri
/Users/drbrain/.multiruby/install/1.9.2-p290/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.0/lib/nokogiri.rb
$ ~/.multiruby/install/1.9.2-p290/bin/ruby -rnokogiri -ve 'p Nokogiri'
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.0]
Nokogiri

=end

[trans (Thomas Sawyer)]

How was this fixed? I updated to latest 1.9.3-rc1.

$ cat req.rb
p "Custom Require"

module Kernel
alias :require0 :require

def require(*a)
  puts "Kernel#require"
  p a
  require0(*a)
end

class << self
  alias :require0 :require

  def require(*a)
    puts "Kernel.require"
    p a
    require0(*a)
  end
end

end

$ export RUBYOPT="-r./req.rb"
$ ruby -rstringio -e'puts'

"Custom Require"

And nothing else is outputed.

[drbrain (Eric Hodel)]

=begin
req.rb doesn't seem to match your description:

$ ruby -rmyplugin script.rb

It tells me "no such file" for myplugin.

Where is myplugin.rb? If it is in a gem this should work fine as I've shown above. If it's in the current directory maybe you need to add "." to the load path, it is no longer present in ruby 1.9.

Turns out the
problem is that the -r option uses internal require code
and thus circumvents rubygems or any modified #require,

This is no longer true as I've demonstrated above. require is modified in lib/rubygems/custom_require.rb. Loading your script directly works fine too:

$ ruby19 -r./req -rstringio -e0
"Custom Require"
Kernel#require
["stringio"]
$

so
even though my RUBYOPT="-rubygems", it makes no difference.

There's no need to RUBYOPT="-rubygems" anymore. RubyGems is present by default.

I've also been informed that RUBYOPT is applied after -r
options, which makes for an additional problem. Apparently
this so -T can ignore RUBYOPT? But if that's the only
reason, then -T should be preparsed from ARGV b/c having -r
options load first prevents augmentation and use of what
RUBYOPT loads by -r. RUBYOPT is supposed to set the
environment, but it isn't much of an environment if its not
there when I run a ruby command.

The discussion on when options from RUBYOPT is parsed appears not to be part of your problem.

=end

[trans (Thomas Sawyer)]

Shall I try again to explain what should be obvious? I use a custom load manager for development. It works well and I have used it for years. However there are issues with special cases. autoload is one. -r is another. b/c of this my load manager can never be feature complete. That you say this is fixed is nothing more than an exception for one and only case, that of rubygems. all other cases that might redefine require will still have these limitations. These cases may include alternate package manages like rip, or load monitors, and so forth.

I report this issue only that Ruby might be feature complete and that I might make use of these features. If it is never to be so, then Ruby might as well make require unredefinable and be done with it. Of course, if that were originally the case, RubyGems would never have been possible either.

[drbrain (Eric Hodel)]

This is the first time you have mentioned that you are using a custom load manager.

As I've shown above with your req.rb example, a custom loader works fine with -r. It is not a special case for RubyGems. It is a problem of when your custom loader is loaded, not that it cannot work.

You should file a new feature request like "RUBYOPT should be parsed before ARGV so require may be overridden".

You should include your req.rb, and the results of the following invocations:

RUBYOPT=-r./req.rb ruby -rstringio -e0

ruby -r./req.rb -rstringio -e0

You should ask for the output of both invocations to be identical.

Since -r no longer uses only rb_require() and will use an overridden Kernel#require this feature request should remain closed.

[nobu (Nobuyoshi Nakada)]

Eric Hodel wrote:

You should file a new feature request like "RUBYOPT should be parsed before ARGV so require may be overridden".

-T option should prohibit RUBYOPT, so the request should like:
"libraries given by -r options in RUBYOPT should be loaded before ones in direct command line arguments".

[trans (Thomas Sawyer)]

Thank you, Eric. I do believe that may be the most helpful comment you have ever given me. Even beyond this particular issue, it provides me some additional clarity on how best to present issues in the future.