I've been working with ruby and gems since ruby 1.8.7. As I mentioned I haven't upgraded to Cap 3, all of my infrastructure is built with capistrano 2, and the cap-recipes gem at https://github.com/donnoman/cap-recipes
I use custom bundler recipes https://github.com/donnoman/cap-recipes/blob/master/lib/cap_recipes/tasks/bundler/install.rb ruby: https://github.com/donnoman/cap-recipes/blob/master/lib/cap_recipes/tasks/ruby19/install.rb passenger: https://github.com/donnoman/cap-recipes/blob/master/lib/cap_recipes/tasks/passenger/install.rb nginx based passenger: https://github.com/donnoman/cap-recipes/blob/master/lib/cap_recipes/tasks/nginx_passenger/install.rb among many others. I have not made the decision to upgrade cap-recipes to cap3. I don't particularly like the cap3 dsl. and Cap3 removed some of the items that allows my recipes to work, like the missing :on hooks. The removal of method_missing to locate variables increases the level of effort to upgrade cap-recipes. I'm considering forking cap2 and renaming it to be a different project to separate it from cap3. I haven't made a final decision on it. I'm going to finally fork cap-recipes to be it's own gem separate from it's parent fork, and I may try to upgrade one or two recipes to cap3 to determine the LOE and see if I can live with the dsl. If I can, then I'll upgrade cap-recipes to cap3. If the baby is ugly, then I'll fork cap2. On Sat, Feb 1, 2014 at 11:15 AM, Douglas Magnenat < douglas.magne...@gmail.com> wrote: > 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 capistrano+unsubscr...@googlegroups.com. > 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. > -- 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 capistrano+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/CABV8oinCj0YOEO5sQKjftL%3DL5ugeR4mgZZHu7vNuBpVArPOE0w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
