RVM is one of those tools that you add to your arsenal that makes you go back and think how you ever got by without it before. This is particularly true if you are working on multiple projects, all of which have their own Ruby versioning/gem set requirements. It's incredible how trivial management has become when I'm dealing with 1.8.7, 1.9.2 and JRuby 1.5.2 (concurrently) on an almost daily basis.
Another important think to note when using RVM is to not use 'sudo' when installing gems. It is easy get caught up in a README or tutorial and execute 'sudo gem install...' as listed in the document. Unfortunately, this installs the gem in root's environment, which isn't configured with RVM goodness using the default installation method and you'll quickly end up with all sorts of problems and obscure error messages.
Personally I find it a bit of an overkill for me, and I doubt that it plays nice with other package managers... (if anyone knows more I'd like to hear more about it).
That said I understand people doing a lot of work on other people's computers (e.g. Ruby on Rail) may find it really useful.
That's what kept me from it, but if you use Ruby you're already using two layers of package managers (your system package manager manages Ruby and RubyGems, RubyGems manages gems). Putting RVM in the middle just deepens that. Being able to quickly switch Ruby versions for different projects is a big convenience.
Exactly. My fear actually started when I realised exactly that. Now, maybe it works beautifully... dunno, and if someone does please enlighten me. :)
I can see the appeal of something like RVM. But despite using Ruby a lot, it's mostly stuff for myself so I just use whatever it's the latest. The reason why I thought about RVM was that I wanted to try MacRuby (and rare cases when I need to move back to the system's ruby) and was suggested to use RVM.
If it's just you, doing stuff for yourself, RVM may not bring a lot of new to you: Correct.
RVM is great to test against different versions (and implementations), especially if you do a lot of team-work: For instance, if you work in a team, or in production environments, the newest version of Ruby may be ahead of the production version, and then it's a must being able to switch from one version, or implementation, to another--painlessly.
A personal use case I could come up with (there are a lot of them): You make an app., and it runs with Ruby 1.9.2. You deploy this app., and then Ruby 1.9.3 is released, and your app. is no longer compatible. You want to stay on the cutting-edge still, so you want 1.9.3, but your project is not compatible with 1.9.3, and still needs some work to be, since it's grown rather huge. Here RVM would be handy!
When I was just toying around with Ruby, I didn't use RVM either. It's not until I've got work within the Ruby field, I've had the need for it. :)
I haven't had any problems, and I even have a hand-installed Ruby 1.9.2 on the system level. (rvm plays well with this: "rvm system").
I haven't noticed any clashes even in this case. By default your rvm is installed for just one user. So if you're all that worried I'd create a different user to try out rvm, and just install rvm on that user. Then if it fucks up you can nuke that user.
If you want to play with MacRuby and keep a more standard Ruby that you already have installed, rvm may be a good choice.
Geesh... you couldn't spent two secs to actually reply?
I wasn't trying to throw FUD: I very clearly stated where I was coming from, and that it was only a doubt.
I also asked for some information, from people who knew more. You seem to, but you felt better just to bash me without providing any helpful hint. Your choice.
Finally it wasn't a criticism as such: as I explained I don't need to have 4 different ruby versions installed and to swap between them. On the other hand, I fear that having macport > rvm > gem in order to install a gem may be a bit too much. Hence why I didn't install it.
shrugs suit yourself, though personally it seems you are the one contributing absolutely nothing.
rvm juggles your bash path for you. When you say '$ rvm use 1.8.7' your 'gem' command is now the one for rvm's 1.8.7
It doesn't conflict with anything and you don't really need to think about it. '$ gem install whatever' and it just works on rvm.
Do you use whatever ruby comes on your system or do you install the one single ruby you use? If the later, it's much easier to install it with rvm and rvm will keep it in a nice little box that doesn't screw with any other ruby on your system. You can get rid of it with a single 'rm' if you want to.
You were throwing fud. You could have asked, "how does rvm do xyz?". Instead you decided to state that you doubt it makes your life easier and probably makes it hard, based on nothing. That's the very definition of fud. Here's what you said, "Personally I find it a bit of an overkill for me". Really, based on what? Does that sound like "only a doubt"?
Let's make a distinction: I found it a bit of an overkill and I still do. That's not a fact, it's my opinion, but if you read other people replying to my post, they agree (that is that it is an overkill for my situation).
I'm not sure what kind of broad all encompassing definition of fud you have, but in that sentence there is both a "Personally" and a "for me". If from that you can't get that it's an opinion and that I am not arguing with everyone then I am not sure what to tell you.
Oh, and btw I said that it was "only a doubt" because you were quoting a different sentence, this one: "I doubt that it plays nice with other package managers", and I think it's pretty obvious why that should sound like a doubt. Now you go and quote a different sentence... why did you change quote?
Anyway bottom line is that I don't think it was FUD at all, and I think most people here seem to have read it the way it was meant it. If suddenly suggesting that RVM may not be the tool for EVERYBODY upsets your sensitivity, that's your problem. Topic over from my pov.
===As for your actual contribution====
My ruby is installed in /opt by macport (my package manager). Hence both ruby and rubygems are inside there (and I think I had to redefine some environment variables for it to work fine). Macport and rubygems already don't play too nice with each other in the sense that if I install something with rubygem macport is not aware, and if a macport package requires some gems it will try to install them via macport. (I may be wrong about this, it's my understanding from a brief overview).
RVM would be a third layer as pointed out by philwelch. Now it may very well be very clever and work like a charm, but I think I was more than justified in feeling a doubt.
we do not need to use sudo to install gems, as everything is kept in ~/.rvm
It's not that you don't need to, it's that you shouldn't. Using sudo to install gems will do so outside of your rvm gemset, and so the gems you install this way will not be available to your app using the gemset.
How does that gemset stuff fit in with Bundler? It's much easier for us to just keep Gemfile in the git repo, run "bundle install", and then let Bundler worry about installing gems and keeping a clean gem environment.
Gemsets simply allow you to have an isolated environment. If you want to install the gems from multiple projects in the same gemset the choice is yours.
Bundler just makes installing each project's dependencies easier.
The pattern I started to use recently was to check in include an .rvm file with the same gemset name as the project.
This way, I simply clone the project, install bundler, and then issue bundle install and my project is ready to go.
`--create` creates a gemset if it doesn't already exist, and `--rvmrc` makes a .rvmrc file to automatically switch to that gemset when you cd into the current directory. This makes it easy enough, that I have a gemset per application/project, and then use bundler to install the deps.
