Add a global version

[tostr7191]

Hi

I use your gem to deploy our rails apps, which works perfectly. But I want to start our application server from systemd. Which does not work right now, because rbenv does not have a version set.

To alleviate this problem I have created a task like this inlib/capistrano/tasks/rbenv.rake:

namespace :rbenv do
  task :set_global_version do
    on roles(:app) do
      rbenv_ruby = fetch(:rbenv_ruby)
      rbenv_path = fetch(:rbenv_path)
      execute "echo #{rbenv_ruby} >> #{rbenv_path}/version"
    end
  end
end

Would this be something that you would consider adding?

Thanks & Best tostr

[mattbrictson]

Although I am a maintainer of this gem, I currently do not actually use capistrano-rbenv, so I will leave this open to other maintainers to comment. @will-in-wi ?

My instinct is that this feels more like a server provisioning task, and thus doesn't really fit the typical use case for Capistrano. In my experience, including a .ruby-version file in my repository is a better solution for telling rbenv what version of Ruby is required.

[tostr7191]

Oh my! I had a .ruby-version file, but it must have gotten removed accidentaly! After recreating it, I don't need that task any more. It appears I created a quite complex solution to a very simple problem ;)

In that case I dont need that feature anymore, it still might be handy (especially in tandem with a task to set up the .bashrc for rbenv). I understand the idea of seperate server/app orchestration, but for me the rbenv & ruby versions etc. is firmly part of app. Because (from my sysadmin perspective) I don't care if the rails app is based on 2.2 or 2.3 etc., I just want to provide "a space for a house to be built" basically. Also I don't need to change the server if the rails dev (which is also me in this case) needs to update the ruby version.

But keeping it simple is ofc. also understandable.

[will-in-wi]

The "right" solution is to have the .ruby-version file in your repo, as previously discussed.

I've used this gem in a couple of situations. However, in almost all of them, I used rbenv primarily so that I could have multiple versions of Ruby available to a set of applications. If the global version file were changed, best case nothing would happen as every project would have their own local ruby version set. Worst case, other projects would break as the version of ruby got changed out from under them (and possibly the paths to their gems).

In the very specific case where your environment need to set the ruby version like this, I think the solution is either to use server orchestration (Ansible, Puppet, Chef, whatever) or write your own task like you have above.

As an aside, on a lot (most?) of system-wide installations of rbenv on servers, rbenv itself is owned by a different user than the deployment and cannot be changed anyway.

So I wouldn't add a task like this. However, this may be a good candidate for the cookbook! http://capistranorb.com/documentation/tasks/intro/

[will-in-wi]

In a previous job, I set up Puppet to do pretty much exactly like you said: Puppet would, on a per-app basis, create a user for the app along with a bashrc file to set up rbenv, which pointed at the system rbenv install, also managed by Puppet.

[tostr7191]

I'll look into rbenv system install, that sounds like it would make my setup simpler (running rbenv user atm). Thanks for the info!