Rails - May 2006 - vendor/rails seems to be being ignored in preference to gem?

I have edge rails in /vendor/rails on DreamHost, but when running 
dispatch.fcgi I get the following error in my logs:

[02/May/2006:08:52:32 :: 29365] terminated gracefully
[02/May/2006:08:53:53 :: 19526] starting
[02/May/2006:08:53:54 :: 19526] Dispatcher failed to catch: undefined 
method `clear_connection_cache!'' for ActiveRecord::Base:Class 
(NoMethodError)
 
../config/../vendor/rails/activerecord/lib/active_record/base.rb:1138:in 
`method_missing''
   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/dispatcher.rb:76:in 
`reset_after_dispatch''
   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/dispatcher.rb:46:in 
`dispatch''
   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:141:in 
`process_request''
   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:53:in 
`process!''
   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:52:in 
`each_cgi''
   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:52:in 
`process!''
   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:22:in 
`process!''
   ./dispatch.fcgi:35

I get the same printed to the shell when running dispatch.rb too.

It appears to me that it''s trying to use the gem version of rails on DH
and not the copy I have in /vendor/rails.

Any ideas on why this is happening, or things to check, would be 
appreciated.

Thanks in advance.

-- 
R.Livsey
http://livsey.org

Quick update on this...

Running script/server or the console etc... also result in the GEM being 
used instead of the version in /vendor/

Certainly odd and I''m at a bit of a loss!

-- 
R.Livsey
http://livsey.org

Richard Livsey wrote:
> I have edge rails in /vendor/rails on DreamHost, but when running 
> dispatch.fcgi I get the following error in my logs:
> 
> [02/May/2006:08:52:32 :: 29365] terminated gracefully
> [02/May/2006:08:53:53 :: 19526] starting
> [02/May/2006:08:53:54 :: 19526] Dispatcher failed to catch: undefined 
> method `clear_connection_cache!'' for ActiveRecord::Base:Class 
> (NoMethodError)
> 
> ../config/../vendor/rails/activerecord/lib/active_record/base.rb:1138:in 
> `method_missing''
>   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/dispatcher.rb:76:in 
> `reset_after_dispatch''
>   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/dispatcher.rb:46:in 
> `dispatch''
>   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:141:in 
> `process_request''
>   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:53:in 
> `process!''
>   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:52:in 
> `each_cgi''
>   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:52:in 
> `process!''
>   /usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:22:in 
> `process!''
>   ./dispatch.fcgi:35
> 
> I get the same printed to the shell when running dispatch.rb too.
> 
> It appears to me that it''s trying to use the gem version of rails
on DH
> and not the copy I have in /vendor/rails.
> 
> Any ideas on why this is happening, or things to check, would be 
> appreciated.
> 
> Thanks in advance.
>

On Tue, 2006-05-02 at 19:31 +0100, Richard Livsey wrote:
> Quick update on this...
> 
> Running script/server or the console etc... also result in the GEM being 
> used instead of the version in /vendor/
> 
> Certainly odd and I''m at a bit of a loss!
> 
Hi Richard,
Have you found a solution for this yet?

I am seeing the same problem, and hope to work on it tonight, so fingers
crossed and maybe I''ll post a solution soon.

cheers,
mick

Look at your environment.rb and the development.rb and production.rb 
files in config/environments. Make sure there are no declarations 
specifying a version of Rails or to use gems. If you still don''t see 
anything, I suggest posting the files so we can have a look.

Mick Hollins wrote:
> On Tue, 2006-05-02 at 19:31 +0100, Richard Livsey wrote:
>> Quick update on this...
>> 
>> Running script/server or the console etc... also result in the GEM
being
>> used instead of the version in /vendor/
>> 
>> Certainly odd and I''m at a bit of a loss!
>> 
> 
> Hi Richard,
> Have you found a solution for this yet?
> 
> I am seeing the same problem, and hope to work on it tonight, so fingers
> crossed and maybe I''ll post a solution soon.
> 
> cheers,
> mick

-- 
Posted via http://www.ruby-forum.com/.

Hi Richard and Mick.

I had the same problem with Dreamhost as well. There were two  
solutions for me. My app uses Engines and the problem was somehow  
related.

The first solution was easy, but a bit of a hack since you have to  
modify files in /vendor/rails. If you follow this thread:

http://forum.textdrive.com/viewtopic.php?pid=87987

near the end, there''s a suggestion to replace the lines require  
''fcgi_handler'' and require ''dispatcher''.
These two modifications
fixed the problem, however I hate the idea of having to modify any  
rails code.

I realized that for me, the new Engines from svn was causing the  
problem. Since the two versions (the previous one that had to issues)  
and the new version that broke my app (on Dreahost, works fine on my  
powerbook) had the same version (1.1.1) I didn''t realize there were  
any differences until I decided to run diff. Anyway, I reverted to  
the last working engines code from svn, and things started working  
again, phew!

I don''t know if the cause is the same, but I had the same problems as  
you guys and that''s how I fixed it. Hope this helps.

-Tak.

On May 2, 2006, at 2:31 PM, Richard Livsey wrote:
> Quick update on this...
>
> Running script/server or the console etc... also result in the GEM  
> being used instead of the version in /vendor/
>
> Certainly odd and I''m at a bit of a loss!
>
> -- 
> R.Livsey
> http://livsey.org

On Thu, 2006-05-04 at 09:32 -0400, Takashi Okamoto
wrote:
> Hi Richard and Mick.
> 
> I had the same problem with Dreamhost as well. There were two  
> solutions for me. My app uses Engines and the problem was somehow  
> related.
Problem diagnosed:

I''m using Engines as well. I tracked it down to the following code in
vendor/plugins/engines/lib/engines.rb:

    #load this before doing ANYTHING freaky with the reloading.
    begin
      require ''rails_version'' # Rails 1.0, 1.1.0
    rescue LoadError, Gem::Exception
      require ''rails/version'' # renamed as of Rails 1.1.1
    end

As I am running Rails 1.1.2, in order to get the correct rails version
file being loaded I need the first "require" above to fail, so that
the
rescue kicks in and the second "require" loads the
"rails/version.rb"
from vendor/rails/....

Unfortunately, in my case (on Dreamhost) the first require does not fail
as the Rails 1.0 gem is available.

If I change the above code to simply say:

   require ''rails/version''

then my app works just fine.

It strikes me that this is a more general problem than the offending
"require" above as there could be any number of such
"requires" that
cause the wrong gem to be brought in.

I suspect the correct solution is for me to set things up so that I:

a) freeze every gem that I use, and
b) configure my rails app in such a way that it never looks for gems
outside of my application''s directory

Now, I think (a) is achieved by following instructions from pages such
as:
http://nubyonrails.com/articles/2005/12/22/freeze-other-gems-to-rails-lib-directory

For (b) I seem to recall reading how to do that somewhere, but will have
to do some more googling.

Anyway, I hope the above helps others who hit this problem, and if
anyone has advice on how to do (a) and (b), or whether that''s actually
what I should be doing, it would be much appreciated.

cheers.
mick

This particular fix is already present in the current release branch
for the engines plugin, and should be out very soon.

- james

On 5/5/06, Mick Hollins <mick@hollins.id.au>
wrote:
> On Thu, 2006-05-04 at 09:32 -0400, Takashi Okamoto wrote:
> > Hi Richard and Mick.
> >
> > I had the same problem with Dreamhost as well. There were two
> > solutions for me. My app uses Engines and the problem was somehow
> > related.
>
> Problem diagnosed:
>
> I''m using Engines as well. I tracked it down to the following code
in
> vendor/plugins/engines/lib/engines.rb:
>
>     #load this before doing ANYTHING freaky with the reloading.
>     begin
>       require ''rails_version'' # Rails 1.0, 1.1.0
>     rescue LoadError, Gem::Exception
>       require ''rails/version'' # renamed as of Rails 1.1.1
>     end
>
> As I am running Rails 1.1.2, in order to get the correct rails version
> file being loaded I need the first "require" above to fail, so
that the
> rescue kicks in and the second "require" loads the
"rails/version.rb"
> from vendor/rails/....
>
> Unfortunately, in my case (on Dreamhost) the first require does not fail
> as the Rails 1.0 gem is available.
>
> If I change the above code to simply say:
>
>    require ''rails/version''
>
> then my app works just fine.
>
> It strikes me that this is a more general problem than the offending
> "require" above as there could be any number of such
"requires" that
> cause the wrong gem to be brought in.
>
> I suspect the correct solution is for me to set things up so that I:
>
> a) freeze every gem that I use, and
> b) configure my rails app in such a way that it never looks for gems
> outside of my application''s directory
>
> Now, I think (a) is achieved by following instructions from pages such
> as:
>
http://nubyonrails.com/articles/2005/12/22/freeze-other-gems-to-rails-lib-directory
>
> For (b) I seem to recall reading how to do that somewhere, but will have
> to do some more googling.
>
> Anyway, I hope the above helps others who hit this problem, and if
> anyone has advice on how to do (a) and (b), or whether that''s
actually
> what I should be doing, it would be much appreciated.
>
> cheers.
> mick
>
>
>
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
* J *
  ~

On Fri, 2006-05-05 at 17:33 +0100, James Adam wrote:
> This particular fix is already present in the current release branch
> for the engines plugin, and should be out very soon.
Thanks James.
Out of interest, what does the fix actually do?

My conclusion was that I should really be changing my ways so that, as I
said, I should
> a) freeze every gem that I use, and
> b) configure my rails app in such a way that it never looks for gems
> outside of my application''s directory
Does the fix make the above unnecessary?

thanks,
mick