Load/require with '..' paths

Dear Jrubyists,

After upgrading from 1.2.0 -> 1.5.x, loading using relative paths is
not working the same way as before:

file ./hi.rb:
puts ‘Hi!’
file subdir/main.rb:
load ‘…/hi.rb’

run: ok
$ jruby1.2 -Isubdir subdir/main.rb
Hi!

run: error
$ jruby1.5.3 -Isubdir subdir/main.rb
subdir/main.rb:1:in `load’: No such file to load – …/hi.rb
(LoadError)

I tracked this change down to a commit between 1.3 and 1.4, in
LoadService.tryResourceFromLoadPathOrURL:
http://github.com/jruby/jruby/commit/777efc73695b27db5bb1a7696c16747e924762ac#L5L788.

I have no real doubt that change was needed (it’s more consistent with
MRI), just wondering of a way around this…
I’m embedding JRuby into an app where I’d prefer to resolve those ‘…’
paths relative to the script loading them rather than relying on pwd.

  1. To support ‘…’ in require/load, do I have to cwd to the dir where
    script is? Or is there a nicer way?

  2. There seems to be some relevant code in LoadService to handle
    relative paths, eg. end of init():
    // “.” dir is used for relative path loads from a given file, as in
    require ‘…/foo/bar’
    but I don’t see how that comes into play as that change I mentioned
    above seems to inhibit the effect of “.” Loadpath entries.

  3. For cwd, ScriptingContainer has a method setCurrentDirectory() but
    this doesn’t have any effect if called after any ‘put()’ calls (I
    guess due to lazy initialization of the runtime).
    Is this intended / documented?
    Should I use to container.getRuntime().setCurrentDirectory() instead?
    (this seems deprecated though)

Any clarifications are welcome. Thanks,

Gergo


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Fri, Oct 8, 2010 at 8:41 AM, Gergely N. [email protected] wrote:

run: ok

// “.” dir is used for relative path loads from a given file, as in
require ‘…/foo/bar’
but I don’t see how that comes into play as that change I mentioned
above seems to inhibit the effect of “.” Loadpath entries.

Let me comment on this:

  1. For cwd, ScriptingContainer has a method setCurrentDirectory() but
    this doesn’t have any effect if called after any ‘put()’ calls (I
    guess due to lazy initialization of the runtime).
    Is this intended / documented?
    Should I use to container.getRuntime().setCurrentDirectory() instead?
    (this seems deprecated though)

As you guessed, put() method triggers Ruby runtime initialization.
ScriptingContainer’s setCurrentDirectory() method sets directory to
RubyInstanceConfig object. The current directory value of that object
is used only when Ruby runtime is initialized. After the
initialization is completed, the current directory value of Ruby
runtime is used. So, ScriptingContainer#setCurrentDirectory method
doesn’t work once Ruby runtime is created.

I’m not sure changing current directory after runtime is initialized
doesn’t break other stuffs. Is there any possible problem? If not,
I’ll change that part so that setCurrentDirectory() method works even
after the runtime is initialized.

-Yoko

Both;
load File::expand_path(‘relative_path’)
and
require File::expand_path(‘relative_path’)
works for me (win XP jruby1.5.3). See;

[2010/10/16] [ 9:53:41.03] [C:_MyPrg\Jruby]
jirb
irb(main):001:0> File::expand_path(’…\ruby’)
=> “C:/_MyPrg/ruby”
irb(main):002:0> File::expand_path(’…\ruby\array-perm.rb’)
=> “C:/_MyPrg/ruby/array-perm.rb”
irb(main):003:0> load File::expand_path(’…\ruby\array-perm.rb’)
=> true
irb(main):004:0> require File::expand_path(’…\ruby\array-perm.rb’)
=> true

hth gfb

----- Original Message -----
From: “Yoko H.” [email protected]
To: [email protected]
Sent: Friday, October 15, 2010 22:03
Subject: Re: [jruby-user] load/require with ‘…’ paths

On Fri, Oct 8, 2010 at 8:41 AM, Gergely N. [email protected] wrote:

run: ok

// “.” dir is used for relative path loads from a given file, as in
require ‘…/foo/bar’
but I don’t see how that comes into play as that change I mentioned
above seems to inhibit the effect of “.” Loadpath entries.

Let me comment on this:

  1. For cwd, ScriptingContainer has a method setCurrentDirectory() but
    this doesn’t have any effect if called after any ‘put()’ calls (I
    guess due to lazy initialization of the runtime).
    Is this intended / documented?
    Should I use to container.getRuntime().setCurrentDirectory() instead?
    (this seems deprecated though)

As you guessed, put() method triggers Ruby runtime initialization.
ScriptingContainer’s setCurrentDirectory() method sets directory to
RubyInstanceConfig object. The current directory value of that object
is used only when Ruby runtime is initialized. After the
initialization is completed, the current directory value of Ruby
runtime is used. So, ScriptingContainer#setCurrentDirectory method
doesn’t work once Ruby runtime is created.

I’m not sure changing current directory after runtime is initialized
doesn’t break other stuffs. Is there any possible problem? If not,
I’ll change that part so that setCurrentDirectory() method works even
after the runtime is initialized.

-Yoko


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Hi Yoko,

sorry for noticing your answer this late.
2010/10/15 Yoko H. [email protected]:

ScriptingContainer’s setCurrentDirectory() method sets directory to
RubyInstanceConfig object. The current directory value of that object
is used only when Ruby runtime is initialized. After the
initialization is completed, the current directory value of Ruby
runtime is used. So, ScriptingContainer#setCurrentDirectory method
doesn’t work once Ruby runtime is created.

OK, my problem that this behaviour is not intuitive for someone how
does not know the internals (ie. ‘put’ happens to initialise the
runtime).

ScriptingContainer.setCurrentDirectory() got added while
container.getRuntime().setCurrentDirectory() is deprecated
-presumably- to isolate clients from internal changes
(http://yokolet.blogspot.com/2010/04/redbridge-what-are-new-and-improved-in.html).
I think this suggests to the user that the former is just the cleaner
and safer way to say the latter; they should be functionally
equivalent.
So I would vote for this behaviour.
(In the worst case, at least throw sg like an IllegalStateException -
to make it obvious that your call didn’t have an effect; and document
it)

I’m not sure changing current directory after runtime is initialized
doesn’t break other stuffs. Is there any possible problem?
I think backwards compatibilty should not be a big issue for
implementing the above: any code that was calling setCurrentDirectory
after ‘put’ just isn’t working - so they very probably don’t have any
expectation on the value of pwd. If they do - those will be really
trivial to fix.

If not, I’ll change that part so that setCurrentDirectory() method works even
after the runtime is initialized.
Please do, it would be nice to remove deprecated calls from our code.
Thanks in advance!

Gergo

2010/10/16 GianFranco B. [email protected]:

Both;
load File::expand_path(‘relative_path’)
and
require File::expand_path(‘relative_path’)
works for me (win XP jruby1.5.3). See;

What you’re doing here, from require/load perspective, is just using
absolute paths.
That’s cool but I was asking about:

require ‘…/relative_path’
load ‘…/relative_path’

Thanks,
Gergo

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs