1.9 require problem

[James Byrne]

As of this morning I am just starting to work with Ruby 1.9. I note
that there seems to be some behaviour change between 1.8 and 1.9 with
respect to require. Specifically, I have this construct.

#!/usr/bin/env ruby

require File.dirname(__FILE__) + '/../lib/deploy/pg_access_setup'

PGAccessSetup::Main.new(ARGV).execute

With ruby 1.8 this works exactly as I desire. With ruby 1.9.2-p0 I get
this behaviour instead:

<internal:lib/rubygems/custom_require>:29:in `require': no such file to
load -- bin/../lib/deploy/pg_access_setup (LoadError)
from <internal:lib/rubygems/custom_require>:29:in `require'
from bin/pg_access_setup:3:in `<main>'

I have spent some time googling for answers to this and I have checked
this forum's archives for hints. I am either using the wrong terms or
not understanding what I am reading. Whatever the matter is, I cannot
decipher what the difference is.

If anyone here can tell me what I need to change to get this to work
under Ruby 1.9 AND Ruby 1.8 I would be most obliged,

 

[James Byrne]

As of this morning I am just starting to work with Ruby 1.9. I note
that there seems to be some behaviour change between 1.8 and 1.9 with
respect to require. . .

If anyone here can tell me what I need to change to get this to work
under Ruby 1.9 AND Ruby 1.8 I would be most obliged,

I discover that if I do this:

require File.expand_path(
File.dirname(__FILE__) + '/../lib/deploy/pg_access_setup')

Then the problem is resolved. However, I do not understand why this is
now necessary or what benefit accrues from introducing this change in
behaviour between 1.8 and 1.9.

 

[Robert Klemme]

I discover that if I do this:

require File.expand_path(
File.dirname(__FILE__) + '/../lib/deploy/pg_access_setup')

You can as well modify $: or set RUBYLIB in the environment.

Then the problem is resolved. However, I do not understand why this is
now necessary or what benefit accrues from introducing this change in
behaviour between 1.8 and 1.9.

Maybe it's not so much a change in behavior or rather a changed default
setting of $:.

Kind regards

robert

 

[Luis Lavena]

  .  .


I discover that if I do this:

require File.expand_path(
          File.dirname(__FILE__) + '/../lib/deploy/pg_access_setup')

Then the problem is resolved.  However, I do not understand why this is
now necessary or what benefit accrues from introducing this change in
behaviour between 1.8 and 1.9.

$LOADED_FEATURES now tracks files with full paths to avoid requires
with File.dirname(__FILE__) load the same file twice.

 

[James Byrne]

$LOADED_FEATURES now tracks files with full paths to avoid requires
with File.dirname(__FILE__) load the same file twice.

I see. Is there some reason that require does not issue an error that an
absolute path was not provided instead of just reporting that it cannot
find the file? The error message that is presently given simply reports
the path used by require and does so in such a way that the necessity to
provide an absolute path is not evident at all. The fact that an ls -l
of the path reported together with the .rb extension will actually find
the file required adds to the confusion.

I understand the intent of the change. And I take it that
require_relative was provided to maintain the old behaviour. However,
this situation does seem to require a little more in the way of an
explicit explanation of the probable cause of the errors which
inevitably result from using 1.8 code with 1.9.

 

[James Byrne]

I understand the intent of the change. And I take it that
require_relative was provided to maintain the old behaviour. However,
this situation does seem to require a little more in the way of an
explicit explanation of the probable cause of the errors which
inevitably result from using 1.8 code with 1.9.

OK. This is not good. If I try to use require_relative I discover that
backtracks in the directory tree are ignored. For instance, given this
code:

#!/usr/bin/env ruby

lib_path = File.dirname(__FILE__) + '/../lib/forex/hll_forex_ca_feed'
puts lib_path
puts("Library file found? " + (File.file?(lib_path + '.rb')).to_s)
require_relative lib_path
HLLForexCAFeed::Main.new(ARGV).execute

I would expect that the file ./bin/../lib/forex/hll_forex_ca_feed.rb
would be found. Instead, when I run this program I see this:

$ bin/forex

bin/../lib/forex/hll_forex_ca_feed
Library file found? true

bin/forex:9:in `require_relative': no such file to load --
/home/byrnejb/Software/Development/Projects/proforma.git/bin/lib/forex/hll_forex_ca_feed
(LoadError) from bin/forex:9:in `<main>

Note that the path determined by require_relative:

home/byrnejb/Software/Development/Projects/proforma.git/bin/lib/forex/hll_forex_ca_feed)

does not accommodate the /../ portion of the relative path provided.
It simply discards it.

In my opinion, the path should read:

home/byrnejb/Software/Development/Projects/proforma.git/lib/forex/hll_forex_ca_feed

or

home/byrnejb/Software/Development/Projects/proforma.git/bin/../lib/forex/hll_forex_ca_feed

Is this intended behaviour?

 

[James Byrne]

OK. This is not good. If I try to use require_relative I discover that
backtracks in the directory tree are ignored. For instance, given this
code:

Now I discover something even worse. If I change the the lib_path by
adding an additional /.. then the thing works. That I do not
understand.

$ bin/forex
bin/../../lib/forex/hll_forex_ca_feed
Library file found? false
$

If this is intended behaviour then I do not understand why the
additional /.. is necessary. As it stands, if this is intended, then it
means that writing code to work with 1.8 and 1.9 ruby that uses
require_relative will need different relative paths to the same file.