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.
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:inrequire’
from bin/pg_access_setup:3:in `’
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,
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,
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.
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 $:.
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.
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.
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.
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:
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
Note that the path determined by require_relative:
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.