
RVM (Ruby Version Manager) 1.0.0 - earcar
http://wayneeseguin.beginrescueend.com/2010/08/22/ruby-environment-version-manager-rvm-1-0-0/
======
earcar
RVM 1.0.0, Ruby 1.9.2 and Rails 3.

\+ Rubinius will remove the GIL ("the work has already begun" -- Yehuda Katz
[http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-
alre...](http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-already/))

\+ MacRuby will be even faster, more stable and more documented

It will be an awesome end of 2010/2011 for Ruby programmers.

~~~
dasil003
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.

~~~
ptn
I'm confused about Bundler and rvm's per-project ruby and gemsets, what's the
difference?

~~~
wuputah
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!

~~~
dasil003
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.

------
JoelMcCracken
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.

------
draegtun
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>

~~~
telemachos
Wow. I just want to record how cool this feels. I got posted on Hacker News by
someone other than me. Thanks.

~~~
draegtun
You're very welcome.

And yes... I know that exact same feeling :)
<http://news.ycombinator.com/item?id=1151932>

------
Pistos2
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.

------
jamesbritt
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.

------
blowmage
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/>

------
jshsu
best feature: hopping on irc #rvm on freenode for instant assistance

~~~
telemachos
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.

~~~
dasil003
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>.

------
alexkiwi
If you develop Rails apps, and your not using RVM and gemsets... bless your
heart.

~~~
dmix
Is there a use-case outside of running ruby 1.8 and 1.9 at the same time?

~~~
dmillar
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.

~~~
koenigdavidmj
Sounds like a beastly equivalent of Python's virtualenv?

~~~
regularfry
Beautifully, beautifully beastly :-)

------
cldwalker
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.

------
cldwalker
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

~~~
bgentry
Are you referring to the auto switching of Ruby environments based on a
directory change? If so, this latest version disables that by default

~~~
telemachos
Are you sure about that? _.rvm/scripts/cd_ still has this at the top [1]:

    
    
        # 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
    

Also, the new security features that Wayne mentions in this post suggest that
a _cd_ automatically leads to a check on the directory you _cd_ into. Doesn't
that imply that rvm still has to plug itself into _cd_? (I may be confused
here.)

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...](http://github.com/wayneeseguin/rvm/commit/f9aa3adebcca547924c8095fa7696967bd2d8d15)

~~~
bgentry
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

~~~
telemachos
_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:

    
    
        if [[ "$rvm_project_rvmrc" -ne 0 ]] ; then
    

Everything else in the _cd_ script hangs off that _if_. So by setting the
environment variable, that whole branch (which is the whole script) is skipped
and _rvm_ won't get in front of _cd_.

------
uggedal
How does it compare to the more mature Virtualenv for Python?

~~~
LaGrange
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.

~~~
uggedal
virtualenv -p python2.5 will create a virtualenv with the Python 2.5
interpreter. I like the per-directory dotfile approach for
autodetecting/activating a virtual ruby setup.

~~~
forsaken
Virtualenvwrapper gives you per-VENV postactivate hooks that do the same
thing.

------
stevefink
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.

------
dmillar
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.

