merge rvm1-capistrano3

[mpapis]

as discussed with @leehambley merging projects, I lost my notes for the README.md changes proposed by Lee so just let me know how to better warn users about dangers ofusing installation tasks

[Kriechi]

It bugs me a little bit that bundle exec stuff is going to be mixed into this gem. Also the installing of gems (which would be the work of bundler) is now nested inside RVM-related code.

Did you dual-license in by mistake, or do you really want to? (I'd prefer MIT-only)

Squashing all commits into one would be great too (since this is mostly history related to rvm1-capistrano3).

[mpapis]

I think bundle exec part could be removed - rvm comes with rubygems-bundler which will do it anyway when needed.

The installing of gems could be moved to capistrano/bundler or a new gem that can be used as a replacement for capistrano/bundler - I have no pressure on this one, it was added when capistrano/bundler was still hardcoding one set of parameters for bundle install

I did dual license it be cause the rvm1-capistrano3 was Apache2 licensed, I did not wanted to drop MIT without asking you.

I would squash it into one commit if it was only my work, but there were other people involved and squashing would remove them from history.

[Kriechi]

@baweaver @JiriKolarik @florian-winddle are you all fine with squashing the commits? As far as I see while quickly looking at git blame, only a few lines in the README are in question. I think it would be much cleaner and simpler to review if this PR is a single commit.

capistrano-bundler currently does only two things:

• calling bundle install with a few arguments (all configurable).
• mapping a list of executables to be prefixed with bundle exec (also fully configurable)

@mpapis are you fine with removing bundle exec and gem install stuff from this PR? Then we can integrate the RG2.2 & Bundler destinction somewhere else.

[kirs]

Wow! :christmas_tree:

I'm totally up to merge these two projects, but I would like to avoid pushing large magic bash script that cannot be supported by Capistrano team.

Also I'm against placing RVM installer inside the gem. RVM team may update it, fix bugs or do whatever -- and we will have to update capistrano-rails at the same time.

[mpapis]

the magic shell script has tests https://github.com/capistrano/rvm/pull/34/files#diff-ac3764a47ec732f55ed08b9e3fb63351R1 + I'm fully taking responsibility of maintenance of this code (I'm available 24/7 - almost ;) - seriously I already look into all the cpaistrano/rvm tickets + I'm maintainer of RVM so I know best how to work with it (and I think I have shown already that I know how to work with capistrano)

as for RVM installer it is not included here, the wrapper https://github.com/capistrano/rvm/pull/34/files#diff-c37e3ada084a04e2e5ac033654f5435bR1 - is included to provide minimal silencing of curl to not produce huge outputs, similar version of this code is used in rvm-capistrano gem, if you prefer I can use this => https://github.com/mpapis/capistrano-slient_curl instead (a version upgraded for cap3)

[Kagetsuki]

@kirs that magic install script is fantastic and saves a lot of headaches. Besides, if you are using RVM you're trusting @mpapis anyway. I absolutely want this merge to happen and I want it to happen soon.

Also everybody needs to give @mpapis money now https://www.bountysource.com/fundraisers/489 so he can continue to make our lives easier. Thanks @mpapis !

[docwhat]

@mpapis

It seems like it doesn't handle the situation where the ruby version you want isn't installed yet. For example, cap rvm:install:ruby fails with a message about ruby not being installed.

In addition, there are lots of invoking of deploy:updating which cause a bunch of overhead for things that don't need all of RVM or even any RVM.

e.g. I have tasks that call upload! to upload init scripts, etc. that don't need RVM yet they still call rvm:check and rvm:hook as well as deploy:updating.

Ciao!

[mpapis]

@docwhat cap rvm:install:ruby worked last time I checked it - can you show me the deploy output?

[mpapis]

as for the deploy:updating I was thinking on caching ruby but as long as nobody complained I thought it can stay as it is ...

[docwhat]

@mpapis I can get you the output on Monday. I've set a reminder.

[docwhat]

@mpapis

Here's the trace markers from running rvm:install:ruby:

** Invoke myapp (first_time)
** Execute myapp
** Invoke load:defaults (first_time)
** Execute load:defaults
** Invoke rvm:hook (first_time)
** Execute rvm:hook
** Invoke rvm:check (first_time)
** Invoke deploy:updating (first_time)
** Invoke deploy:new_release_path (first_time)
** Execute deploy:new_release_path
** Execute deploy:updating
** Invoke git:create_release (first_time)
** Invoke git:update (first_time)
** Invoke git:clone (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
** Execute git:clone
** Execute git:update
** Execute git:create_release
** Invoke deploy:symlink:shared (first_time)
** Execute deploy:symlink:shared
** Invoke deploy:symlink:linked_files (first_time)
** Execute deploy:symlink:linked_files
** Invoke deploy:symlink:linked_dirs (first_time)
** Execute deploy:symlink:linked_dirs
** Execute rvm:check
** Invoke bundler:map_bins (first_time)
** Execute bundler:map_bins
** Invoke rvm:install:ruby (first_time)
** Invoke deploy:updating 
** Invoke rvm:hook 
** Execute rvm:install:ruby

[docwhat]

Whups, wrong info, @mpapis. Here's the right info for the failed rvm:install:ruby...

** Execute rvm:check
DEBUG [55623bb7] Running /tmp/myapp/rvm-auto.sh rvm version on staging-myapp.example.com
DEBUG [55623bb7] Command: /tmp/myapp/rvm-auto.sh rvm version
DEBUG [55623bb7]
DEBUG [55623bb7]   rvm 1.23.10 (stable) by Wayne E. Seguin <wayneeseguin@gmail.com>, Michal Papis <mpapis@gmail.com> [https://rvm.io/]
DEBUG [55623bb7]
DEBUG [55623bb7] Finished in 0.473 seconds with exit status 0 (successful).
rvm 1.23.10 (stable) by Wayne E. Seguin <wayneeseguin@gmail.com>, Michal Papis <mpapis@gmail.com> [https://rvm.io/]
DEBUG [4effcea9] Running /tmp/myapp/rvm-auto.sh rvm list on staging-myapp.example.com
DEBUG [4effcea9] Command: /tmp/myapp/rvm-auto.sh rvm list
DEBUG [4effcea9]
DEBUG [4effcea9]   rvm rubies
DEBUG [4effcea9]
DEBUG [4effcea9]      ruby-1.9.3-p194 [ x86_64 ]
DEBUG [4effcea9]      ruby-1.9.3-p429 [ x86_64 ]
DEBUG [4effcea9]      ruby-1.9.3-p448 [ x86_64 ]
DEBUG [4effcea9]
DEBUG [4effcea9]   # Default ruby not set. Try 'rvm alias create default <ruby>'.
DEBUG [4effcea9]
DEBUG [4effcea9]   # => - current
DEBUG [4effcea9]   # =* - current && default
DEBUG [4effcea9]   #  * - default
DEBUG [4effcea9]
DEBUG [4effcea9] Finished in 0.608 seconds with exit status 0 (successful).
rvm rubies

   ruby-1.9.3-p194 [ x86_64 ]
   ruby-1.9.3-p429 [ x86_64 ]
   ruby-1.9.3-p448 [ x86_64 ]

# Default ruby not set. Try 'rvm alias create default <ruby>'.

# => - current
# =* - current && default
#  * - default
DEBUG [02eb1705] Running /tmp/myapp/rvm-auto.sh rvm current on staging-myapp.example.com
DEBUG [02eb1705] Command: /tmp/myapp/rvm-auto.sh rvm current
DEBUG [02eb1705]      system
DEBUG [02eb1705] Finished in 0.455 seconds with exit status 0 (successful).
system
DEBUG [80599ca5] Running /usr/bin/env if test ! -d /opt/myappuser/staging/releases/20140106201236; then echo "Directory does not exist '/opt/myappuser/staging/releases/20140106201236'" 1>&2; false; fi on staging-myapp.example.com
DEBUG [80599ca5] Command: if test ! -d /opt/myappuser/staging/releases/20140106201236; then echo "Directory does not exist '/opt/myappuser/staging/releases/20140106201236'" 1>&2; false; fi
DEBUG [80599ca5] Finished in 0.240 seconds with exit status 0 (successful).
DEBUG [9a575771] Running /tmp/myapp/rvm-auto.sh 1.9.3-p484
 ruby --version || true on staging-myapp.example.com
DEBUG [9a575771] Command: cd /opt/myappuser/staging/releases/20140106201236 && /tmp/myapp/rvm-auto.sh 1.9.3-p484
 ruby --version || true
DEBUG [9a575771]      Ruby ruby-1.9.3-p484 is not installed.
cap aborted!
ruby stdout: Nothing written
ruby stderr: Nothing written
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/command.rb:94:in `exit_status='
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/netssh.rb:142:in `block (4 levels) in _execute'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:551:in `call'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:551:in `do_request'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:561:in `channel_request'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:465:in `dispatch_incoming_packets'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:221:in `preprocess'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:205:in `process'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `block in loop'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `loop'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `loop'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:269:in `wait'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/netssh.rb:164:in `block (2 levels) in _execute'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:514:in `call'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:514:in `do_open_confirmation'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:545:in `channel_open_confirmation'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:465:in `dispatch_incoming_packets'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:221:in `preprocess'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:205:in `process'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `block in loop'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `loop'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `loop'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/netssh.rb:166:in `block in _execute'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/netssh.rb:123:in `tap'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/netssh.rb:123:in `_execute'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/netssh.rb:76:in `capture'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/bundler/gems/capistrano-capistrano-rvm-2232346dc04a/lib/capistrano/tasks/rvm.rake:9:in `block (4 levels) in <top (required)>'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/abstract.rb:81:in `within'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/bundler/gems/capistrano-capistrano-rvm-2232346dc04a/lib/capistrano/tasks/rvm.rake:8:in `block (3 levels) in <top (required)>'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/netssh.rb:54:in `instance_exec'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/backends/netssh.rb:54:in `run'
/usr/local/var/rbenv/versions/1.9.3-p484/lib/ruby/gems/1.9.1/gems/sshkit-1.3.0/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
Tasks: TOP => rvm:check

[mpapis]

@docwhat but it worked in the end? the system can be improved capistrano-rvm is still in early stage (version 0.1.0) which means breaking changes can be expected. I spent already over an hour mapping rvm1-capistrano3 source to capistrano-rvm, I would like to avoid future changes before merge is accepted or rejected - I can either work on one or another project, I will not spend time on the branch not knowing if this will get merged. I would like to get clear decision from current maintainer before continuing work on this (I was asked to do the merge by @leehambley after I had to implement my own solution because my ideas were rejected in this project).

[mpapis]

ah that's problem from applying the capistrano-rvm code on rvm1-capistrano3 during merge ... I can look into it if there is still good will to merge it

[docwhat]

@mpapis -- I understand; I wouldn't want to work a branch if it'll never be accepted.

@kirs -- Do you have unresolved concerns about this pull request? The sooner you decide the direction, the sooner people (me!) can start testing it.

[Kagetsuki]

@docwhat I think you just unintentionally brought up a good point: we should be testing this before it's merged. May I ask who has actually tested? We're doing some refinement on a Rails site right now so I'll have @snowsunny give it a shot.

[mpapis]

@Kagetsuki this code was working as rvm1-capistrano3 for some time already, the only unexpected pain points would be from moving the code around and from merging it with capistrano-rvm - like the one @docwhat found

[Kagetsuki]

@mpapis we were actually using both plug-ins in tandem before so I don't expect issues. I think I can trust you if you say the merge is good - and we'll test just after merge for double verification.

So, @kirs, merge it?

[mpapis]

@Kagetsuki there is the one issue found by @docwhat - it is not related to the core and should not be hard to fix, I will work on it and retesting everything as I get confirmation it is intended to be merged

[kitchen]

any word on this? I'd love to get cracking with this!

[kirs]

The problem is that Capistrano team is not going to support any of bash scripts from this PR and we're totally against RVM/Ruby installation scripts inside the gem. This kind of things are done with Chef, Puppet or Ansible (or maybe manually). Capistrano is a tool to put new release on the server, not to setup it.

[docwhat]

@kirs

Then please close this.

[Kagetsuki]

@kirs while I completely understand your position on the bash scripts I'd like to point out that I've never used RVM-Capistrano to install RVM system wide. I've always used it to install a local RVM on an isolated user account often on shared hosts. Using Chef to do that seems like overkill. That's not to say that I don't see your point - it's just a shame I have to spend hours to start integrating yet another tool to do something I was doing in ~3 simple lines of code with Cap2.

[mpapis]

@kirs then I'm completely confused, please talk with @leehambley, he asked me to open this PR, the shell scripts that you refuse to support make the difference and I offered my help to support them - I do already look into all issues in capistrano-rvm and I maintain RVM so it makes sense I would be looking into capistrano-rvm support too ... btw I have asked for your opinion two weeks ago (+ @docwhat & @Kagetsuki also did asked too), with no response, I can give faster response times to the projects

[Kagetsuki]

@kirs, after @mpapis last comment I'm looking back up the thread and I'm thinking your only real issue is the bash script?

Also:

and we're totally against RVM/Ruby installation scripts inside the gem

You could have pointed that out about a month ago when less work was put into this. I'd say over half the people here want this merge to happen almost specifically for that functionality. @mpapis spent the time to give us what we want here despite the fact he has a lot of other things he could be focusing his time on.

[kabturek]

So is this PR dead ? :confused:

[docwhat]

@kabturek It seems like it. I've just resigned myself to using rvm1-capistrano3. shrug

[Kagetsuki]

This puts me off Capistrano 3 so much... but there's really no other tool I want to be using for deployment. I'm conflicted, but at least we have rvm1-capistrano3.

@kirs I'm sure you're busy but if you could at least provide some sort of feedback on the issue we'd really appreciate it.

[kirs]

@Kagetsuki here is the feedback: https://github.com/capistrano/rvm/pull/34#issuecomment-31350612

I know that Michal is available almost 24/7, but as long as nobody from core team can read or modify code from this PR, we cannot merge it.

[Kagetsuki]

@Kirs you said in comment 34:

but I would like to avoid pushing large magic bash script that cannot be supported by Capistrano team.

Two points on this. 1. @mpapis is offering to maintain it. 2. the only people who will be using RVM are people who would have bash on their system anyway.

By not accepting this you're also just asking for issues with interoperability of Capistrano official RVM extension and the rvm1-capistrano3 gem. Are we supposed to use one or the other or both? I hate to say it but your official version has proven to be almost completely worthless for me. If you don't accept this PR I'd actually rather you removed your official RVM extension to avoid confusion and having two different standards for the same thing.

[leehambley]

@mpapis pinged me via email to re-awaken this topic. I can state clearly that I did agree with him in principle on merging this. But I'm also aware that it's completely against what I intended for Capistrano. Installing Rubies is a provisioning problem, and Capistrano is a deployment tool. I think that deploying new rubies automatically, and installing them _during_ the deployment process is a terrible, terrible idea and that however clever the code might be to make that happen, it scares the shit out of me that people build houses of cards on top of a tool that I work hard to keep stable. I don't really care whether it's merged or not, I'd prefer to see consensus than a battle of wills, but I also think that using RVM in production is for amateurs. (Whilst acknowledging that @mpapis worked really hard to improve that situation, it's still fundamentally solving the wrong problem at the wrong level of abstraction in my opinion)

[docwhat]

@leehambley

I totally understand and I agree in principle.

Unfortunately there aren't any really good solutions for being able to transition and manage ruby versions yet. There are some proto-ideas in Chef space but none work reliably on all platforms.

Fortunately, as people figure out how to do this then the need for this extension goes away.

Meanwhile, this is a good stop-gap for certain values of "production". For example, we run apps in house that use this. I can live with the uncertainty and problems we inherit because it isn't a problem if the apps are down for a little.

Finally, this plugin is a fast way to get up-and-running; one can switch to something more reliable later.

If you find it undesirable to keep this under the 'capistrano' brand, then I'd suggest just giving this repo to @mpapis and wiping your hands of it (if he'll take it).

If you'd rather keep it under the 'capistrano' brand, then I'd still suggest giving @mpapis commit access and rubygems.org access so that things can be fixed quickly by the RVM expert.

No matter what you do, we all are grateful for your work on Capistrano.

[Kagetsuki]

@leehambley So I've been using Capistrano wrong all this time. When I change Ruby versions I should do what? Is there a guide on how Capistrano should be used/how you would ideally like it to be used? If so I would love to read that.

However, for us we have servers that handle several clients. Each client has a home directory and each client has access only to that directory. They use Capistrano to deploy and to install a local Ruby with RVM. Having RVM automatically version check and install a new Ruby if needed made deploys as simple as Heroku. Cap2 made our lives much easier. Then Cap3 came and now I've had a constant headache with deploys for months.

I'm assuming capistrano/rvm is so crippled because you don't agree with my/our deploy philosophy. If that's the case then it's exactly like @docwhat says - either give this repo to @mpapis or destroy this repo entirely. You shouldn't waste your time and our time poorly maintaining something you don't care about and don't agree with and, in the process, creating an incompatible double standard with rvm1-capistrano3 which someone does care about and does agree with.

[sauliusgrigaitis]

I'll throw a bit of my own petrol to this fire:

1) I like an idea to dedicate Capistrano for deployment only, because this restriction helps to maintain things in clean and nice shape. I saw too much of terrible servers setup code in deploy.rb files. I personally manage tens of servers for tens of apps and I use system wide RVM installed by Chef on all these servers. This works great for my team, but probably doesn't work great for others.

2) I tried to use capistrano/rvm without any luck. Switched to @mpapis version and he fixed all the problems I reported.

3) I see the only one solution for this problem - let @mpapis maintain capistrano/rvm and merge his version except RVM installing related code. If during deployment code detects that RVM or some Ruby is not installed, then it crashes with message "Can't find RVM, please install RVM or add third-party gem rvm1-capistrano3-installer". In this way many peeps will use official capistrano/rvm and some will add some black magic from third-party.

[mpapis]

@sauliusgrigaitis one question: do you let install gems during deploy or you have separate chef run for your gems?

for me both language libraries and language itself are application dependencies, why allow installing the libraries (gems) which might require some system level libs (mysql) and not allow installing the language, both are application dependencies.

I guess this topic is subjective, it all depends on the point of view, for some people ruby is just another dependency of the application, and if you allow installing gems which are also dependency ... why is it ok to install one dependency during deploy and why it is not to install another?

[sauliusgrigaitis]

I use Bundler for sure. I understand your point, but with such philosophy we can lead to ideas that app server or even OS is just dependency of the app. So then Capistrano should do everything including servers provisioning. That's not good.

Regarding to system libraries (for mysql etc). There are only few such libraries and I install it via Chef. My deployments are sudoless, so deployer can't install system libraries. I think this is good approach, because in this way I maintain list of system libraries in Chef configs, so during next server setup I don't have to reinstall these libraries manually.

I personally don't see Ruby as library dependency, because it's very coupled with app server. I manage Ruby with Chef, because Ruby paths, versions etc. are used in app servers and other configs, and that should not be managed with Capistrano. I'm forced to lock Ruby version in all configs and start scripts, because for me the only reliable way to use RVM is to run Ruby processes using rvm-shell specifying exact Ruby version. So if Capistrano manages Ruby versions, then it must update servers configs too, that's not good.

Yes, this topic is very subjective. And I understand peeps that do things differently than me, because their way works better in their situation, mine works better in mine. So I see the only one solution to solve this opinionated problem - split into two gems.

[mpapis]

maybe I should explain what the current code base does (rvm1-capistrano3) - by default if the ruby is not installed it will fail and warn about missing rvm/ruby, but you get access to two tasks to install rvm and ruby, it's your choice if you call them manually, if you add before 'deploy:cold' or if you add it before :deploy

so now what RVM provides is making users life as easy as possible, this is:

• when you install RVM - it is automatically added to shell initialization files
• when you install ruby - it is automatically used
• when you install gems - wrappers are automatically created

now if it would be up to me I would always update rvm and made sure ruby is installed during deploy, but I understand not everybody wants that so those actions are disabled by default, but easily available - it's just one line (each) to enable rvm / ruby installation.

as an extra we could pull the installation code to separate gem - but I would keep it as dependency so users do not have to modify multiple files to enable that functionality, try to not make things harder when it can be done simply - especially for beginners - they just want to put that app on server, not read 1001 tutorials describing how to configure deploy (where half is for wrong version), just make it simple - this is my goal - if this gem does not want to make things simple for users - then I will be happy to continue providing the simple solution in rvm1-capistrano3, I was an user too.

[sauliusgrigaitis]

I'm ok if installation code is shipped as dependency. But if there are arguments against it, then I'm ok with informative error message that describes how to install and configure gem that contains installation code.

[codedmart]

Please merge these projects. I was getting a Warning about my rvm PATH not being set right. rvm1/capistrano3 solved all my issues. Thanks @mpapis

[mpapis]

@kirs @leehambley what is the status for it now? are you waiting for more action from me? what should I do to make it happen?

[Kagetsuki]

@mpapis I have one thing to say for your persistence: dziękuję I kid you not me and @snowsunny are banging our heads on a new deployment setup right now. If this were merged it would remove some confusion. @kirs you can make this better for everyone who uses RVM or you can continue giving us headaches. Use the merge button ↘

[Kagetsuki]

AGE :up:

[Kagetsuki]

@kirs @leehambley Please, any response is better than no response. I'll give you credit if you just respond with "busy" or "thinking" but this continued lack of any response is increasingly making me dislike Capistrano. @mpapis is trying to make something he is partially responsible for work with Capistrano and he's doing it very well. Your continuing to ignore him and not make a decision means that people will continue to write conflicting plugins for Capistrano 3 because some people use the crippled "official" rvm extension and some people use the fully functional rvm1-capistrano3 extension.

I'm an OSS dev as well. I understand the constant conflict of keeping money coming in and being busy with clients while also trying to maintain something. Still, I at least try to be courteous enough to give a short response when I am busy. Can you at least do that for us?

[mpapis]

closing as the team is clearly not interested in merging

[Kagetsuki]

@mpapis Thanks anyway.