Where does Ruby look to load files?

Ruby
1

Can someone explain what changed from 1.9.1 to 1.9.2 with regards to
where Ruby finds or resolves other required .rb files?

Also there must have also been some changes from 1.9.2 to 1.9.3.

I have a lot of .rb files in the same directory, things were working and
now it complains that it cannot find a .rb file.

thanks

2

That little thing called Google again…

https://www.google.com/search?q=ruby+require+1.9.1+1.9.2

John

3

I did indeed google this. I was more confused afterwards. The articles
are very poorly written, no specific examples.

It seems like there are a lot of google articles. If there were an
article on the Ruby forum in a wiki it would be great.

4

It is going to take two days to fix one application alone; We have many
web apps on Ruby. This is a serious hit on time; and I can imagine
there are many other out there that have to dedicate resources to this.

Can anyone explain exactly what the “security risk” was and why the Ruby
dev team could simply not leave this alone?

We cannot afford this type of downtime or resources to rewrite an app
everytime some yahoo Ruby dev thinks he is being clever by fixing a
security risk that is probably a result of irrational fear of some
extremely remote possibility of something happening.

I have seen enough of Ruby in the week dealing with it and will be
making the recommendation to rip it out entirely because of the
maintenance headache associated with it and the Ruby core devs who think
things like this are a bright idea.

5

Why upgrade to 1.9.3 then? Why no testing in advance of the upgrade?

Valid points or not concerning any change to the core of the language -
it’s always your responsibility to ensure things work prior to upgrading
major pieces of your infrastructure isn’t it?

You have made about 3-4 posts today and not one of them has been
anything
but negative. So you don’t like ruby it appears - well that’s
unfortunate
and I’m sure if you took the time you would see the light - but that’s
not
going to help you right now either way.

So how about asking some more positive questions on the subject?

You said it would take a week to fix this - why so long for 2 small
issues
you’ve discussed thus far?

The DBI issue seems like a single line of a patch to a single file to
remove that issue. And quite frankly I think it makes perfect sense to
not
be able to add something to a list of items while you are running
through
that list. And the fix is equally simple to understand - run through a
copy
and modify the original if needed. 10 minutes and done.

And the load path issue (require failing) has been addressed multiple
times
and it’s not that hard - something like this added at the top of your
files
should solve that issue. Even 100 or so files doesn’t take that long to
shove something like this in.

$:.unshift(File.expand_path(File.dirname(FILE))) unless
$:.include?(File.dirname(FILE)) ||
$:.include?(File.expand_path(File.dirname(FILE)))

That simply adds the ‘.’ folder back into your load path. 2-3 hours max
here for a lot of files? If you truly have that many files there are
always
tools like sed and friends that can help (but I hate pulling them out
unless I REALLLLLLLLY need to :slight_smile: ).

I understand the frustration - but you certainly are not engendering
much
help from others with the off the cuff ranting.

John

6

On Mon, Jun 3, 2013 at 4:10 PM, Jeremy B. [email protected] wrote:

… and I can tell you that your problems can be summarized as:

  1. Lack of understanding of the tools you’re using (Ruby and its libraries).
  2. An application code base that was allowed to bit rot for too long.

Not to mention:

  1. Lack of (apparently) any production environment change control.
  2. Lack of (apparently) any kind of tests, automated or otherwise.
7

On 06/03/2013 03:47 PM, J. V. wrote:

It is going to take two days to fix one application alone; We have many
web apps on Ruby. This is a serious hit on time; and I can imagine
there are many other out there that have to dedicate resources to this.

You do realize that the change to Ruby that is giving you problems here
was released almost 3 years ago, right? Upgrading your application’s
basic infrastructure after such a lag should be expected to take some
time and effort. Try to stay calm. This one has some workarounds
available.

If you would like to avoid large code changes and accept all the risks,
you can play with fire by appending ‘.’ to the library path for Ruby.
Locate one of the first files loaded by your application, and add this
near the top:

$: << ‘.’

Now your library search path is as unsafe as earlier versions of Ruby,
and the rest of your application can go about business as before.

Can anyone explain exactly what the “security risk” was and why the Ruby
dev team could simply not leave this alone?

Maybe you already ran across this discussion:

Read it closely because it does explain the reasoning down in the
comments.

Calling require can happen at any time during the execution of your
application. If require looks in the current working directory of the
application for files to load, it can be tricked into loading the wrong
files or simply failing to load anything at all by the application’s
working directory being something other than expected at the time
require is called. This could be the result of maliciousness, a poorly
coded library, race conditions in threads, the user running the
application from an unexpected location, or anything else that could
trigger even a momentary change of the application’s current working
directory.

While the risk may generally be remote, it is real, and requiring the
majority of developers to explicitly exclude the current working
directory from the library path because they don’t need it is guaranteed
to fail somewhere along the way. It’s better to start secure and allow
those few who need this functionality to tweak their applications to
enable it or find better methods so that they don’t need it either.

Could these changes have been implemented in some way that preserved
backward compatibility? Maybe so, but the backward compatibility would
eventually need to be removed in the name of security anyway. Would
your application have been able to make use of that even after 3 years?
Maybe not.

There was quite a bit of angst at the time this change went live years
ago. You’re just a little late to the party.

We cannot afford this type of downtime or resources to rewrite an app
everytime some yahoo Ruby dev thinks he is being clever by fixing a
security risk that is probably a result of irrational fear of some
extremely remote possibility of something happening.

I can understand your frustration, but remember that if you truly want
help, casting about insults is not going to garner much assistance.
Please also consider that in this case you may not actually know better
than the Ruby developers on this particular point.

I have seen enough of Ruby in the week dealing with it and will be
making the recommendation to rip it out entirely because of the
maintenance headache associated with it and the Ruby core devs who think
things like this are a bright idea.

Best of luck finding an application stack that can be ignored for years
and then upgraded without the need to touch any of your own application
code to account for API changes. I’ve been where you are now
personally, and I can tell you that your problems can be summarized as:

  1. Lack of understanding of the tools you’re using (Ruby and its
    libraries).
  2. An application code base that was allowed to bit rot for too long.

If your team no longer has any Ruby expertise, it probably makes sense
to go with something you know instead. Unfortunately for you, you’ll
still likely have to support your application in its current form while
you rewrite it from scratch. It would be best to accept that and try to
avoid alienating those who may help you through this in the meantime.

-Jeremy