

A story of PROMPT_COMMAND and RVM - mpapis
http://niczsoft.com/2012/12/story-of-prompt_command-and-rvm/

======
kawsper
RVM can really bite you if you are not careful. And it can really mess things
up <https://github.com/wayneeseguin/rvm/issues/1234>

Right now I am looking for an alternative on my servers, because I need
different Ruby versions across projects.

It is very interesting history following the development of RVM, to Rbenv and
now also Chruby. It seems like 37signals is going the way of Rbenv.

It will be interesting to follow. It seems like a really fundamental problem,
that need to be solved for us to build good software.

~~~
RegEx
Do any of these behave like Python's virtualenv? I really like how virtualenv
works, and if I ever want to get semi-serious with Ruby, I'd like to have
something similar.

~~~
regularfry
Not for managing the Ruby version itself, but I wrote gemenv
(<http://github.com/regularfry/gemenv>) to be able to have the same style of
contained package management that virtualenv offers. There's no reason you
couldn't ./configure --prefix=gemenv and build a ruby binary into it as well.

~~~
themckman
You can use virtualenv to manage the python version, also. If you have
multiple versions of python installed, say python27 and python3, using the
--python option of virtualenv you can tell it which executable you want to
create the virtualenv with.

Honestly I always felt the various multi-ruby helpers were a bit too much for
me. I just compiled my rubies my self setting --prefix during configure and
then would just adjust a few env variables to set up things like PATH and
GEM_HOME and had no issues.

~~~
regularfry
That's what I mean - I specifically wanted gemenv _not_ to worry about
installing rubies. It does one job, and one job _only_ :-)

------
RegEx
This post is 30% technical, 70% politics.

Essentially, the author is upset that the author of rbenv[0] decided to
criticize rvm instead of opening tickets and whatnot.

The author then goes on to blame the rbenv author for the year long delay in
implementing PROMPT_COMMAND in rvm.

> We could have this code available for rvm users one year ago, possibly we
> could have a lot more of good solutions if the problems were discussed
> instead of throwing accusations as it was done by rbenv author.

[0]: <https://github.com/sstephenson/rbenv>

~~~
manojlds
It makes sense to raise the issue before blaming about it. That's what Open
Source is supposed to be.

~~~
regularfry
There comes a point where you think "I disagree with so many of the design
decisions this project took that I don't have the energy to chase up every
last consequence." _Well before_ that point it becomes reasonable to kick off
another project to flesh out your own ideas. Competition is good.

