Though I agree it is a bad idea to mix different rubies on the same server, I disagree not using RVM to install a solo ruby. I spent my weekend try to solve gems issues with Phusion Passenger :
1) Despite I said at the begining of my first post-question. *I finally will* use *capistrano-rvm* and *capistrano-bundler*. Ruby and gems would give me far more headache if I wouldn't use RVM and bundler. It doesn't exist proper tutorial on Internet to install ruby taking care of ruby locatin, access rights, path, environnement variables, gems locations, etc... The complexity of ruby environnement appears to be one of the reasons why RVM has been developed. 2) Now without capistrano-bundler having for me generated this complexe parametered bundle command ( It s not just a "bundle install") I would have spent ages to understand what to do to perform a proper deployment : Capistrano and Capistrano-bundler take care of it for me. 3) As Phusion Passenger is no more installed as a gem but as a package (on debian) It also comes with an apt-get dependency : ruby package 1.9.3 Unfortunately when I installed my ruby version 2.1.0, I thought this was the only ruby version installed. This lead me to a pain.... troubelshooting why Phusion passenger was complaining not finding my gems. After ours of fighting with gems, I was happy to find a dedicated section to RVM into Phusion Passenger guide : http://stackoverflow.com/questions/21477087/why-does-passenger-says-that-my-gem-json-cant-be-found-when-my-gem-list-show To be short, Ruby and his Gems is so much a pain.... for me (and many people I guess) that I'm really happy to have helping tools such as RVM, Capistrano and capistrano-bundler to ease my life of developer. So that I can concentrate on coding my app. I'm really gratefull to developers that took time to develop such tools ! Great thanks ! Le samedi 1 février 2014 16:09:11 UTC+1, dbray a écrit : > > I have a hard fast rule that you should never use rben, rvm or any other > ruby switcher on production or staging boxes. Ruby switching is a > developers tool. Use one and one only version of ruby on a remote box. If > you have two apps that need to use different rubies, and you want to make > them work on the same box. Invest the time required to make the code use > the same version of ruby instead of futzing with a ruby switcher. If you > can't make them use the same version of ruby, in these days of cloud > computing, put the apps on different servers. If you are so hard up for > hardware then use something like LXC to provide that isolation. > > rvm and rbenv are just examples of providing isolation. You can provide > isolation by putting them on different servers or virtual servers and you > will save yourself a lot of pain, and incidentally downtime. In production > I want the fewest dependencies, and when you add a ruby switcher you are > adding a very fickle, complicated, and in my experience unstable dependency. > > That being said, try using the full path to bundle in your rake command. > There are also examples of adding to the path by overriding the call to > the default shell. I don't use cap3 yet so I can only speculate that the > following may work in this one instance. I can pretty much guarantee this > won't be the last time using a ruby switcher is going to bite you. > > SSHKit.config.command_map[:rake] = > "/usr/local/rvm/gems/ruby-2.1.0/bin/bundle exec rake tmp:cache:clear" > > > -- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/68b01b4e-27df-434d-9245-f56f26acacf3%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
