[update] Aussie Rubyists are discussing this on rails-oceania@googlegroups.com
I’m a relative newcomer to Ruby Version Manager (RVM) because I haven’t needed it till now. Last week I started work on a project that uses JRuby and RVM is now a part of my tool chain.
“RVM is a command line tool which allows us to easily install, manage and work with multiple ruby environments from interpreters to sets of gems.”
I think it’s a pretty amazing project and Wayne E. Seguin deserves respect for gifting us with such a great tool. I think it’s great for dev but…
I’m just not sure I want RVM in Production
As I said, I’m new to RVM. I don’t know it that well yet so I’m not qualified to speak about it with any degree of authority. The idea of running rvm on production servers seems wrong to me because it seems to dump a load of non-standard complexity onto sysadmins while ignoring the unix idioms and conventions they know.
Do we really need to be so specific about versions?
In an age of virtualisation and cloud computing, a production server probably shouldn’t need to have more than one version of Ruby installed. RVM makes it easy for devs to specify that this web app uses ruby-1.9.2-p180 while that one uses ruby-1.9.2-p290. I’m just not sure they should be expecting operations to be providing them with such specificity.
Don’t sysadmins have enough to deal with already?
Developers may spend months or years in the same cosy environment working on software they know backwards. Sysadmins deal with chaos everyday. They put out fires, multitask and deal with hundreds of different bits of software. What makes this possible is conventions within the unix world. Logs go here, start scripts there, this is the library load path, etc… System administration can be like working in a busy kitchen. Special off menu orders make their work harder and are not appreciated!
I just wonder whether developers demanding specific Ruby patch levels will come across like the folks ordering coffee from LA Story?
[Update] I was running into a few difficulties using RVM so at least for now, I’ve settled on a very simple use for RVM on my workstation. Bundler does a great job managing my gems so I’ve set RVM to use system Ruby and I’ll only use a .rvmrc in projects that are not using my default of ruby-1.9.2.
If you enjoyed this article, please consider sharing it!
No, we don’t.
And while Wayne hasn’t actually come out and said it, he runs RVM as a tool for developers: frequent updates, shit breaks every so often, moving target, recommend that you always use the latest version, etc etc.
We had RVM on our Ubuntu images for a while, and having “. /usr/local/rvm/scripts/rvm && rvm use ruby-1.9.2 && …” before every command was a pain, as was managing .rvmrc files “what do you mean the deploy hung? Oh, it’s waiting for somebody to type Y to trust the rvmrc”
All issues that can be worked around, but it’s still a pain.
Since moving to a CentOS image with a locked Ruby-1.9.2 install things have been much easier. It’s always ruby 1.9.2, it’s always the one gemset, and bundler does the heavy lifting of making sure gems match their projects.
My recommendation: build images/machines for each version of ruby you need. If this becomes a problem, it’s a sign that you’re using too many different versions of ruby, not that you should be using outside of your local dev environment.
There’s certainly some resistance to using it at work on that basis. Most ops guys I know see the idea of compiling anything from source on a production server (when you could use the package manager) as a lot of work that adds complexity/risk.