RVM (Ruby Version Manager) 1.0.0(wayneeseguin.beginrescueend.com)
wayneeseguin.beginrescueend.com
RVM (Ruby Version Manager) 1.0.0
http://wayneeseguin.beginrescueend.com/2010/08/22/ruby-environment-version-manager-rvm-1-0-0/
15 comments
Don't forget Bundler. There's a lot of ambivalence to Bundler because of the painful journey to 1.0, but it's totally proportional to the difficulty of the problem, and I think they've really nailed it for 1.0.
I'm confused about Bundler and rvm's per-project ruby and gemsets, what's the difference?
In my opinion, Bundler deprecates the need--or at least the need in most cases--to use gemsets. They are still a great feature to give you great control over exactly which gems are installed for testing purposes, but once you switch your applications to using Bundler, there's rarely a need to keep each project in its own gemset.
What Bundler does is establish a container for all gems (and ONLY those gems) that your application needs to run. This is much like an automatic, application-specific gemset.
It also solves the difficult problem of resolving your applications dependencies, locking your gems to a particular set of dependencies to assure consistency across environments and deployments. This is a very critical feature and really showed its ugly head when Rails 2.3.8 was released. Users suddenly found their projects breaking because one gem would load the latest version of activesupport installed on their system (e.g. activesupport-2.3.8) while Rails would require exactly version 2.3.5. Bundler solves this problem by determining that 2.3.5 is the correct dependency and locks the application to only load that version.
It is exactly because of this feature that gemsets are now rarely needed. A large repository of gems will no longer cause you pain and hassle, as Bundler will pick and choose (or install) whichever gems you need to run the project. No more manual management of gemsets. Hooray!
What Bundler does is establish a container for all gems (and ONLY those gems) that your application needs to run. This is much like an automatic, application-specific gemset.
It also solves the difficult problem of resolving your applications dependencies, locking your gems to a particular set of dependencies to assure consistency across environments and deployments. This is a very critical feature and really showed its ugly head when Rails 2.3.8 was released. Users suddenly found their projects breaking because one gem would load the latest version of activesupport installed on their system (e.g. activesupport-2.3.8) while Rails would require exactly version 2.3.5. Bundler solves this problem by determining that 2.3.5 is the correct dependency and locks the application to only load that version.
It is exactly because of this feature that gemsets are now rarely needed. A large repository of gems will no longer cause you pain and hassle, as Bundler will pick and choose (or install) whichever gems you need to run the project. No more manual management of gemsets. Hooray!
In short, rvm operates at the individual developer level, and bundler at the application level.
rvm gemsets are still a great way to have a general purpose Rails 2 setup and Rails 3 setup on the same machine. Granted, if you only work with applications that use Bundler, it's totally unnecessary. But often you will have legacy apps, or you just want to hack around quickly on some code without set up a Gemfile.
rvm gemsets are still a great way to have a general purpose Rails 2 setup and Rails 3 setup on the same machine. Granted, if you only work with applications that use Bundler, it's totally unnecessary. But often you will have legacy apps, or you just want to hack around quickly on some code without set up a Gemfile.
Bundler works together with RVM gemsets. If you have an active RVM gemset, Bundler will use it.
The goal of Bundler is portability between deployments. It answers the question: "How do I package up everything required to run this app so I can deploy it anywhere."
The goal of Bundler is portability between deployments. It answers the question: "How do I package up everything required to run this app so I can deploy it anywhere."
This is one of those tools that you don't realize you're missing until you start to use it.
On OS X, the entire process of installing was painless, straightforward, and took very little time. The process of learning it took even less time.
Highly recommended.
On OS X, the entire process of installing was painless, straightforward, and took very little time. The process of learning it took even less time.
Highly recommended.
Here is a nice post on RVM (and Perlbrew): Two tools you should be using, if you aren't already
http://ithaca.arpinum.org/2010/06/13/rvm-and-perlbrew.html
http://ithaca.arpinum.org/2010/06/13/rvm-and-perlbrew.html
Wow. I just want to record how cool this feels. I got posted on Hacker News by someone other than me. Thanks.
You're very welcome.
And yes... I know that exact same feeling :) http://news.ycombinator.com/item?id=1151932
And yes... I know that exact same feeling :) http://news.ycombinator.com/item?id=1151932
I use RVM for all Ruby installations now. I can't think of a distro or UNIX flavour whose Ruby packages are so good that I would use them instead of RVM. That includes Gentoo, Debian, Ubuntu, CentOS, BSD, OSX.
For those developing Ruby libraries, RVM makes multi-version testing a breeze.
For those developing Ruby libraries, RVM makes multi-version testing a breeze.
At MWRC 2010 I wandered just outside the auditorium and ran into Wayne. I don't think we'd formerly met before, but we got to chatting and I told him I had played around a bit with RVM, but had some questions/issues.
Holy shit. I got the world's greatest crash course on, not just RVM, but bash scripting as well.
Wayne is not only a really nice guy and fun to hang with, but freakin' smart.
Super congrats on reaching 1.0.0.
Holy shit. I got the world's greatest crash course on, not just RVM, but bash scripting as well.
Wayne is not only a really nice guy and fun to hang with, but freakin' smart.
Super congrats on reaching 1.0.0.
RVM is so full of awesome. Specifying a project's gemset with an .rvmrc file is my preferred workflow now. Its a genius tool.
http://rvm.beginrescueend.com/gemsets/basics/ http://rvm.beginrescueend.com/workflow/rvmrc/
http://rvm.beginrescueend.com/gemsets/basics/ http://rvm.beginrescueend.com/workflow/rvmrc/
[deleted]
best feature: hopping on irc #rvm on freenode for instant assistance
This can't be emphasized enough. Wayne's post about 1.0.0 reveals how close to burn out he was, but on the outside, he is seemingly tireless. He is on #rvm so many hours, quickly answering questions, over and above the work he does coding directly for rvm (not to mention his, you know, paying work and life). Sutto has also been in #rvm a lot over the summer I think.
Wayne is a machine. This guy single-handedly revolutionized ruby installation, due in equal parts to technical chops, and just providing amazingly rock solid free technical support to any and all comers on a daily basis.
Please donate http://pledgie.com/campaigns/9822.
Please donate http://pledgie.com/campaigns/9822.
If you develop Rails apps, and your not using RVM and gemsets... bless your heart.
Better option is chef-solo + vagrant. That way, you can version all parts of the system, not just Ruby/Rails.
Is there a use-case outside of running ruby 1.8 and 1.9 at the same time?
I started using this last week to refactor a pile of legacy Ruby code. Gemsets per app is a godsend for that. You can disentangle the giant set of installed gems on your machine, figure out which ones are actual dependencies and which ones are only there because they were part of some crazy experiment six months ago, which ones are only there because they are dependencies of some other gem...
Gemsets for different apps, running MRI vs REE, and really you can run and switch from any flavor of Ruby (including JRuby) in an instant. It handles all the configuration and compilation for installation. Huge time saver, even if you are one of the few that only need one ruby version.
Sounds like a beastly equivalent of Python's virtualenv?
Beautifully, beautifully beastly :-)
If you have a few apps, it makes switching between so much easier. Best way to switch effortlessly between Rails 3 and Rails 2 apps.
If you're using a machine where you don't have root access it makes managing ruby installs and gem installs a lot easier.
it is huge for developing/maintaining a gem since you can run your tests easily across all sorts of ruby versions and gemsets
For those who like rvm for its gemsets, check out rip: http://github.com/defunkt/rip . Supports pushing/popping multiple ripenvs (gemsets) and has sweet support for unix-like command plugins.
rvm is sweet for managing rubies but not so sweet in that it hijacks cd(). I like to cd without any apps meddling.
Recommended fix: $ echo rvm_project_rvmrc=0 >> ~/.rvmrc
Recommended fix: $ echo rvm_project_rvmrc=0 >> ~/.rvmrc
Are you referring to the auto switching of Ruby environments based on a directory change? If so, this latest version disables that by default
Are you sure about that? .rvm/scripts/cd still has this at the top [1]:
I have to admit the cd thing ended up throwing me for an interesting loop at one point. I was scripting and no matter what happened, cd was returning 0 (success) - even when the cd command was actually failing. I could not figure out for the life of me why the right exit status wasn't being reported. It turns out that rvm wasn't saving and then returning the exit status of cd itself. (So the exit status I was capturing wasn't actually that of cd.)
Long story short, two minutes in #rvm and Wayne had it fixed [2].
Edit: I think I see the confusion. Cldwalker is saying that he doesn't like rvm tinkering with cd. Bgentry is saying that rvm no longer automatically switches Ruby if it finds a .rvmrc in a folder (after you cd into it). That's right, but it doesn't change what is bothering Cldwalker: rvm does in fact still get in front of cd. (I think 'hijacking' is too strong, but I know what Cldwalker means by it.) If you use rvm, then by default every time you issue cd, rvm runs the code in [1] (part of which obviously punts to the built-in cd). You can disable this behavior, as Cldwalker says, by setting the environment variable rvm_project_rvmrc to 0. Unless I'm wrong, the default is still on.
[1] http://github.com/wayneeseguin/rvm/blob/master/scripts/cd
[2] http://github.com/wayneeseguin/rvm/commit/f9aa3adebcca547924...
# Source a .rvmrc file in a directory after changing to it, if it exists.
# To disable this fature, set rvm_project_rvmrc=0 in $HOME/.rvmrc
I have to admit the cd thing ended up throwing me for an interesting loop at one point. I was scripting and no matter what happened, cd was returning 0 (success) - even when the cd command was actually failing. I could not figure out for the life of me why the right exit status wasn't being reported. It turns out that rvm wasn't saving and then returning the exit status of cd itself. (So the exit status I was capturing wasn't actually that of cd.)
Long story short, two minutes in #rvm and Wayne had it fixed [2].
Edit: I think I see the confusion. Cldwalker is saying that he doesn't like rvm tinkering with cd. Bgentry is saying that rvm no longer automatically switches Ruby if it finds a .rvmrc in a folder (after you cd into it). That's right, but it doesn't change what is bothering Cldwalker: rvm does in fact still get in front of cd. (I think 'hijacking' is too strong, but I know what Cldwalker means by it.) If you use rvm, then by default every time you issue cd, rvm runs the code in [1] (part of which obviously punts to the built-in cd). You can disable this behavior, as Cldwalker says, by setting the environment variable rvm_project_rvmrc to 0. Unless I'm wrong, the default is still on.
[1] http://github.com/wayneeseguin/rvm/blob/master/scripts/cd
[2] http://github.com/wayneeseguin/rvm/commit/f9aa3adebcca547924...
ah, you are correct, I saw this bit in the release note earlier and then assumed that Cldwalker was referring to the same issue.
So, setting rvm_project_rvmrc=0 will still execute RVM's cd script, but it will skip the part that loads an rvmrc
So, setting rvm_project_rvmrc=0 will still execute RVM's cd script, but it will skip the part that loads an rvmrc
So, setting rvm_project_rvmrc=0 will still execute RVM's cd script, but it will skip the part that loads an rvmrc
Not exactly: setting 'rvm_project_rvmrc=0' causes rvm's cd script to immediately bail out. From .rvm/scripts/cd:
Not exactly: setting 'rvm_project_rvmrc=0' causes rvm's cd script to immediately bail out. From .rvm/scripts/cd:
if [[ "$rvm_project_rvmrc" -ne 0 ]] ; then
How does it compare to the more mature Virtualenv for Python?
It's more comparable to virtualenv with virtualenvwrapper. Also, it manages multiple versions of Ruby (AFAIK virtualenv was coupled to a single version of Python) and has a per-directory dotfile (that way, when I switch to ~/Projects/something rvm automatically switches to correct ruby and gemset).
It generally feels more 'complete' to me.
I didn't do any serious work with virtualenv in quite some time, so this may have changed.
It generally feels more 'complete' to me.
I didn't do any serious work with virtualenv in quite some time, so this may have changed.
Save so much time and energy with this tool. Realized how much more I get done on a daily basis because of it and almost felt guilty not to donate a few bucks.
RVM rocks I can't imagine working without it. Great to see it hit Version 1. Plus, Wayne is, hands down, one of the nicest guys I've ever met.
[deleted]
+ Rubinius will remove the GIL ("the work has already begun" -- Yehuda Katz http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-alre...)
+ MacRuby will be even faster, more stable and more documented
It will be an awesome end of 2010/2011 for Ruby programmers.