user rvm is prefered over system

[mpapis]

In rvm when used manually the user installation should win over system one, this should be persistent for all tools wrapping rvm.

[Kriechi]

:+1:

[kirs]

Did you have any cases of production machine with 2 rvm installed (both user and system wide)?

[mpapis]

I had few users asking for this, actually this code could be more improved by checking for root and RVM_SYSTEM_PATH extra first.

[Kriechi]

@mpapis do you want to change anything else?

otherwise I would would again :+1: the change in behaviour, because mosts deployer-users might only have permissions to install/manipulate the own home directory. Although it really is an edge case and might only concern very few people/setups.

[mpapis]

this is all for this one, I will open new PRs with other improvements.

[kirs]

@mpapis should I make a new release including this fix?

[mpapis]

nah no hurry, I want to add new flags for --install, --create after #16 you can release then

[mpapis]

I mean you can merge now and release new version when extra flags are added

[kirs]

I want to add new flags for --install, --create

I'm not sure if this integration should be responsible for installing rubies. That's usually done with another tools, like Chef or Puppet.

[mpapis]

the create flag has to be here, it is only responsible for creating gemset (placeholder for gems) not installing anything, as for install - it was part of rvm/capistrano and it is a lot simpler then using chef, I do not expect single machines installations to configure chef/puppet, those "extra" tools build additional complicity to the system and make it really hard to debug problems, they are good when you manage farm of servers not a single machine.

[leehambley]

the create flag has to be here, it is only responsible for creating gemset (placeholder for gems) not installing anything, as for install - it was part of rvm/capistrano and it is a lot simpler then using chef, I do not expect single machines installations to configure chef/puppet, those "extra" tools build additional complicity to the system and make it really hard to debug problems, they are good when you manage farm of servers not a single machine.

If it's just about one machine, why not simply create the gemset by hand rather than bloating this library. Feel free to add and inject your own tasks to create Gemsets.

[kirs]

@leehambley :+1:

[Kriechi]

I would agree with @kirs and @leehambley - the capistrano-rvm is should be simply just for integration purposes.

Because "a new server" has to be configured in so many steps prior using capistrano. It would not make any difference - so the RVM install and gemset creation would be better suited in a chef recipe or something similar.

[mpapis]

that's what I call automation, the tools to automate (deployment) are expected to do things for us and make it easy, expecting anyone to involve extra tools/work is just like telling them do it yourself when we know what and how to do (well I know) ... anyway if not in this gem I can add all the automation in capistrano-rvm-manage gem and if you like it it can be moved to capistrano/rvm-manage, this is what users are asking to get.

[kirs]

Sure, then I can mention this gem in README of capistrano-rvm.

[Kriechi]

Mhm I still have an minor issue here. In my mind Capistrano is about deployment. Not setup or configuration.

[leehambley]

Sorry @mpapis but there's only a certain amount of patience I have for saying no.

We've built an easily extensible tool that does the minimum useful feature set without straying into feature creep.

Using RVM in production is not advised (see the massive number of changes and edge cases this Gem has had to accommodate for unusual setups) @kirs is kind enough to support the community by maintaining this package, but we all agree that installing rubies via a deployment tool is a shitty idea.

We've invested a lot of time and energy in this Gem, and Capistrano, and in the interplay and extensibility between them precisely so that people who need more than we are prepared to offer can extend locally, or write gems to add features they need.

So, please respect our wishes, and don't try and push the project in a direction where we've been clear about not wanting to take it.

[mpapis]

@leehambley I understand how much effort is required to create and maintain good tools, along number of ruby tools I am maintaining rvm-capistrano gem which does a lot more and I know how hard it is, this is why I offer my help with maintaining capistrano-rvm and as you can see I try to help. I get asked by users for the functionality of creating gemsets, installing rubies and even installing rvm, it is clear now for me that it is not welcome functionality in this gem and I will work on it externally of this code.