Benefits of RVM

Why should I/should I not use RVM?

I'm new to the ruby language and serve开发者_如何学Pythonrs as a whole. I've had some trouble installing using RVM...so I'm inclined to not use it right now, but it seems like it may make installations down the road easier?

I'm interested to hear about your experience with RVM and your thoughts as it pertains to maintaining a server.

---

RVM is useful even if you don't want to install multiple versions at the same time. I'm a ruby hobbyist (PHP during the day :(), and I have no reason to want to use old versions, but I still use RVM.

Installing ruby is a pain. Getting it from the package manager (at least in ubuntu) gives you an outdated version that changes installation directories from the defaults. I've had nothing but problems with it.

So you think, "I'll just build it from source". Building from source requires getting a load of dependencies and configuring options. Often times I've built ruby only to find out I forgot to enable SSL support or readline support.

RVM takes care of all of this. In 3 or so commands, you have a perfectly built version of ruby.

And I didn't even cover how RVM manages multiple ruby installations for you, which is its killer feature. If you have that need, there is really no other sane solution.

---

RVM is great as this allows your to install different versions without touching your system's default Ruby install. It is rather similar to virtualenv's in Python.

Another great advantage to having RVM are the gemsets - you can create as many gemsets that are unique to the version, and patch level, of ruby.

I've extolled some of its virtues here and you should also see this blog post.

In terms of maintaining a server - let's take a Passenger install for example; do remember that Passenger is installed as a gem, so with rvm the benefit here is that you can have multiple installs of passenger, tied to a different version of ruby. Of course, typically, you'll have Passenger running on one version at a time, although there are ways to have Passenger, in particular, running on different ruby versions.

---

I use different Ruby versions for different projects (that's where .rvmrc is really handy). Some deployment environments are happy with 1.9, while there are a couple of legacy servers using 1.8 for some reasons. Also, occasionally I want to launch a specific version of ruby to compare how they work. RVM does all that for me.

---

When you are first getting used to Ruby, it may not entirely be necessary. That said, what it does is set you up for success in the future. Because once you get hooked, you may end up playing with projects that need to move from, say, MRI 1.8.x to 1.9.x. Or from 1.9.x, to JRuby 1.6.x. My experience is that this happens irregularly, but when it does, there's no substitute for RVM.

Outside of that, the other biggest feature that I use regularly, is the ability to segment one particular release. So I can have an environment for 'stable' gems, and an environment for 'unstable' gems. For instance, while Rails 3.1 has been in release candidate mode, I've had one main workspace for 1.9.2 and a separate space for Rails 3.1.rc? gems on 1.9.2. That makes it possible for me to keep developing my main Rails 3.0 stuff (with one command at the CLI), without having to specify full file paths to the appropriate rails bin files in order to use the older files.

---

If you're using a Debian based platform where the packagers/policy leads to a really bad default installation you'll have a way better experience using rvm.