Rails App doesn't find gems after deploy

[Ramsés López]

Hello all,

I'm trying to implement capistrano to deploy from my workstation to another server. I followed the instructions from 2.x-From-The-Beginning, and I configured my apache server according to this serverfault answer.

However, when I use capistrano to transport it to the other server, the rails app doesn't seems to find methods containen in gems, like paginate from will_paginate. If I remove the references to that gem, then rails will complain about not finding some other method of another gem, like the ones from blueprint-rails.

I'm guessing that it could be some problem with the config of my environment, or maybe in my capistrano config, but right now I'm out of ideas, and don't know what else to check. Any ideas?

Some info that might help:

Ruby:

$ rvm list

rvm rubies

   ruby-1.9.2-p290 [ i686 ]
=* ruby-1.9.3-p194 [ i686 ]

Capistrano:
$ cap --version
Capistrano v2.12.0

My deploy.rb
http://pastie.org/3951922

My Capfile
http://pastie.org/3951928

Thanks! any suggestions will be appreciated

[Hassan Schroeder]

On Tue, May 22, 2012 at 1:28 PM, Ramsés López <ramses...@gmail.com> wrote:

> However, when I use capistrano to transport it to the other server, the
> rails app doesn't seems to find methods containen in gems

> $ rvm list
>
> rvm rubies
>
>    ruby-1.9.2-p290 [ i686 ]
> =* ruby-1.9.3-p194 [ i686 ]

Does `gem list --local` show you the correct gems? Can you start
up a console successfully while logged in?

If so, then your Rails app is probably being run as a different user,
without access to your RVM environment.

If not, run `bundle install` and try restarting your app.

HTH,
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

[Donovan Bray]

I'm going to get up on my soapbox a bit. I believe requiring more than the system version of ruby is a systems operations smell. Your violating some very basic separation of concerns by running dissimilar applications on the same box, and that way lies pain. You are likely creating an all eggs in one basket situation. 

Rvm will only make your life harder and troubleshooting production much more difficult and fragile. Not dissing rvm here; any solution that purports to solve this problem muddies the waters and I don't believe belongs on production. If you want ruby isolation; then do real isolation use more boxes. 

With virtualization you can insulate systems on physical hardware; if you are using a cloud you can use more but smaller instances. If your already on the smallest instance your cloud provider provides and your putting multiple apps on it; neither one is going to perform well and your cutting your nose off to spite your face. Plan for success and give each app a chance to breathe and succeed on their own. 

There's rarely a good argument for trying to run multiple versions of ruby on the same production system.  

On your Dev env knock yourself out; I use rvm with vagrant and rvm inside the vagrant.  But it doesn't belong on production systems. 

--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en

[Lee Hambley]

For what it's worth, I absolutely agree with Donovan in this respect, that said I do use Chef provisioned environments with rbenv, chiefly because rbenv does a better job of installing Ruby and it's obscure dependencies (should we rather say, unintelligent searching of dependencies) and in order to create a layer of separation between my provisioning environment, and my application environment.

All of that being said, I know the risks, I know where to look when things go wrong, and I know that even then, it's a bad idea. (But Chef doesn't make it that easy)

As is almost always the case, people are misunderstanding the way Capistrano works, and relying on dotfile hacks, and shell environment modification scripts (rvm) and wondering why it doesn't work in an environment with no shell and which doesn't source dotfiles.

Rbenv at least provides `local-ruby-exec` which is a replacement for the `#!/bin/env ruby` line, which takes care of the modifications to the environment, this at least makes it tolerable in production, but requires modifications to the PATH, to Capistrano, to the bundle configuration and more, for me this is a worthy trade-off.

I would advise against doing anything with RVM in production, period. If you must (you mustn't) use something like this in production look at rbenv; it's from a 37signals employee, and it's particularly well written. (Don't do it.)

If you are using Chef ( as I am ) and you want to separate Chef from your application, don't - modify your bootstrap to install the system version of Ruby that you desire (I wish I would have done this, but in my position as Cap maintainer I owe it to the community to experiment with various configurations)

- Lee