[bradleyland]

I hate to single you out, but it's become really hard for me to listen to any Ruby developers decry "magic" as a bad thing in RVM. RVM is an excellent tool that was taken down a notch by a hit job needlessly perpetrated by the author of rbenv.

RVM is no more magic than rbenv, and to listen to Ruby developers (who treasure "magic") talk about it as if RVM commits some cardial sin by overriding `cd` tops out my nerd-rage-meter. Ruby, home of the monkey patchers, has no place calling out RVM for overriding `cd`.

RVM and rbenv serve similar purposes. RVM gives you gemsets as well. You may not need them today, but they're there if you do. I use Ruby for a lot of system administrative tasks. These tasks run inside cron jobs and other places where a bundle really doesn't make sense. Despite the fact that they're no longer in vogue, gemsets are still very useful.

Should you check out rbenv? Yes. But the "little less magic" is a really poor basis by which you should evaluate it as a tool.

[mhansen]

Monkey patching in ruby has well-known problems (what happens when two libraries patch the same object?), and now good library maintainers know not to monkey-patch standard libraries. Neither should RVM.

The monkey-patching of `cd` is the main reason I'm not using RVM. I depend on `cd` to work, every time, rock solid, especially when my system is unstable. I can't risk having a dependency or bug in their `cd` script breaking my most commonly used shell command.

rbenv has demonstrated that it's not necessary to override `cd` to manage ruby versions, so why does RVM still do it?

[bradleyland]

The only function of RVM that requires overriding `cd` is the autoloading of .rvmrc, which is easily turned off with a single line of configuration. The topic is so beaten to death that we've even been through one iteration where RVM turned it off by default.

Here's the rub. No one ever has a problem with the overridden `cd` command. Community outcry resulted in a reversion of the default returning to it's original configuration.

What bugs the shit out of me is the band-wagoning from people who, frankly, haven't got a clue. They hear that "there be dragons" in RVM, and all of the sudden everyone is running around flailing their hands over their head like RVM installs a custom kernel or something. It's unwarranted, and it all stems from the original hit job pulled by Sam Stephenson when he released rbenv. Meanwhile, all the same people who are screaming about the "magic" in RVM were cluelessly using it for god knows how long before rbenv came along.

Sam has since apologized and will tell you that RVM is a fine tool, but everyone seems to have forgotten that. If you don't want to use RVM, fine, don't use it, but the "reasons" everyone cites for avoiding it are pretty weak in practice. Wayne is one of the strongest bash programmers I've ever seen. I trust him, and every time I've needed him, he's been available in #rvm for help. Go forth and use rbenv, but you don't have to kick dirt on RVM along the way.

[codenerdz]

Can you explain to me how did RVM cause cd to interfere with your work experience? Im curious because Ive been using it forever and other than it executing my .rvmrc files, havent noticed a bit of difference

[mhansen]

RVM's overriding of cd isn't portable to other shells. I can't use it in my favourite shell (fish).

Yeah, there's http://beginrescueend.com/integration/fish/, but I tried that and it started printing errors every time I used cd due to some bug (this was over a year ago, there's a good chance it's been fixed, but it just left me really shy about overriding cd).

[latortuga]

As an RVM user, I wholeheartedly agree with your main point but I think there's an argument to be made to allow some other program handle gemsets. As it is, when you use RVM you most likely have to add your .rvmrc to your .gitignore. This unfortunately obfuscates what version of Ruby your project is on. Using rbenv is nice in that you can keep that documentation alongside the project where it belongs. Tying the gemset to the version is nice for testing various environments for a single project but doesn't work well when you have to choose between sharing a local development setting with the whole team or not sharing an rvmrc at all.

[bradleyland]

I use Bundler for all my application projects. Fortunately, nothing about RVM forces you to use gemsets. I use gemsets for scenarios where I'm writing code that will not run within an 'application'.

Ruby is my go to language for damn near everything. I use it for working with log files, parsing Excel documents & performing analysis, system administration, you name it. Many of these scripts are one-offs that reside in '~/bin'. RVM allows you to do something like this in your shebang:

#!/usr/bin/env ruby-1.9.2-p290@vqm-analysis

That's the first line in a shell script that I wrote to collect examples of bad calls in a csv file output from an AdTran 900-series VoIP gateway. The CSV file contains about 30 columns of data related to the quality of VoIP calls. I have a collection of five or six scripts that use that gemset, but they're not really an application. They just run from '~/bin', so using bundler isn't really practical. I could wrap them up in a gem and make them a proper application, but this is scripting. Simply using RVM + gemsets saves me a lot of time.

My point is that gemsets may or may not have any utility for you, but it's narrow minded to assume that they have no utility for everyone.

[getsat]

rbenv is a bit easier to use in production (doesn't require any Capistrano addons, etc.) IMO, but for local dev it doesn't really matter one way or the other.