

RVM 2.0: Convert 20,000 lines of shell script into Ruby [Fundraiser] - ccverg
https://www.bountysource.com/fundraisers/489

======
nbouscal
Alternatively, use <100 lines of shell script:
[https://github.com/postmodern/chruby](https://github.com/postmodern/chruby)

~~~
scoot
Or even better, rbenv:
[https://github.com/sstephenson/rbenv](https://github.com/sstephenson/rbenv)

~~~
nbouscal
Better how? I used rbenv before using chruby and while rbenv is a huge
improvement over RVM, I've found chruby to be a further improvement over
rbenv.

------
unwind
How does one write a page like that, without even _trying_ to explain, in a
single sentence, what "RVM" _is_? It surely wouldn't hurt?

I assume that if you don't know (like me), you're not in the target audience
of people willing to chip in to get the conversion done, but it still manages
to frustrate me.

~~~
bstar77
It's definitely something only targeted to Ruby devs. If you use ruby, you
know what RVM is.

To answer your question, RVM is a version manager for Ruby.
[http://rvm.io/](http://rvm.io/)

------
khoury
$50.000? I don't get the amount of cash needed. Not judging, just not
understanding. Could someone explain and justify the need for this?

~~~
tinco
Is not a crazy amount, you have to take into account that it will probably be
a year or more before this port is even close to done. And then take into
account the years of support he will probably offer.

That's not even thinking about all of the service they've provided to our
community already.

I would argue it's on the low side, I sincerely hope he'll go over it.

------
SmileyKeith
I think I'm missing something. If an operating system doesn't come with a
version of Ruby installed at all, how would you run RVM if it was written in
Ruby? Unless it came bundled with a version of Ruby, which sounds bad. I
thought the entire point of having these systems written in bash was to make
them usable _before_ having Ruby installed at all?

~~~
SmileyKeith
After thinking about this for more than 1 second I guess a large portion of
RVM that works after you have Ruby installed, such as rvmsudo, could be based
on Ruby. Leaving the setup code written in Bash.

~~~
bradleyland
There's a Google Doc with a lot more detail as well:

[https://docs.google.com/document/d/1xW9GeEpLOWPcddDg_hOPvK4o...](https://docs.google.com/document/d/1xW9GeEpLOWPcddDg_hOPvK4oeLxJmU3Q5FiCNT7nTAc/edit?pli=1)

Your question is covered under "Bootstrapping"

> Bootstrapping > Using ruby should be possible thanks to binary rubies, in
> worst case we can fallback to static build or use JRuby. The binary Ruby (or
> static or JRuby) will be installed along with RVM 2 using very simple
> bootstrapping script written in shell most likely pure SH to provide
> compatibility with as much systems as possible

I had similar thoughts. The fact that RVM is implemented (currently) in shell
means you don't need Ruby installed. It does, however, expose your tool to all
the idiosyncrasies of someone else's shell environment.

I sit in #rvm on Freenode from time to time and the vast majority of trouble
pings are related to differences in environment. That is to say, if you run a
standard (as in, not heavily customized) environment, you won't have much
trouble. There are a large number of users who _really_ like to tweak their
shell though, so RVM has to face the issue head on.

I think this is what has lead the team to the "bundled" approach. It sounds
like RVM 2.0 will be a full-blown application, rather than a collection of
scripts. The choice to build the application in Ruby, as opposed to something
like C, seems obvious when you consider what it is. Ruby folks want to write
Ruby.

~~~
SmileyKeith
Thanks for the link. That definitely makes sense. They'll get a lot more
involvement from Ruby developers when they wouldn't have to write it in Bash,
that's for sure.

------
davidroetzel
I would love to hear more about "leverage existing package management
systems".

I guess many people use rvm to install ruby and I always recommend newbies to
try it out for that purpose.

But recent criticisms of ruby made me wonder if that really is the right
approach. Maybe it would be better to put more effort into creating top-notch
packages for the major linux distros (and, say, homebrew). And to work with
the distributions on the stable packages, while offering official repositories
to get the latest versions.

rvm could still play a role in this scenario as a tool to switch between
versions, isolate gem installations and so on, offering a unified interface
that hides the platform differences of the distros.

I would certainly donate to such a cause.

~~~
FooBarWidget
Creating proper platform-specific packages is a mad undertaking, requiring
huge amounts of manpower to setup and to maintain. We provide native Phusion
Passenger packages for 5 platforms (3 Ubuntu versions, 2 Debian versions, OS X
Homebrew) and it's already crazy complicated. Check out the toolchain that we
spent months on building:

[https://github.com/phusion/passenger_apt_automation](https://github.com/phusion/passenger_apt_automation)

[https://github.com/phusion/passenger_autobuilder](https://github.com/phusion/passenger_autobuilder)

And this is just _one_ software package. Imagine at least 10 Ruby interpreters
and versions (all versions of MRI 1.8, 1.9 and 2.0, all versions of Rubinius,
all versions of JRuby). Now multiply that by the number of popular platforms.
That's at least 13 (2 supported Ubuntu LTS versions, 1 latest Ubuntu non-LTS
version, 2 supported Debian versions, latest 2 OS X versions, Windows, Red
Hat, Fedora, CentOS, Arch, Gentoo). You'd end up with at least 100 different
packages, and you'll have to test each one of them.

That's going to cost much more than a one-off campaign of $50000.

~~~
davidroetzel
> Creating proper platform-specific packages is a mad undertaking, requiring
> huge amounts of manpower to setup and to maintain.

Of course you are right, and I am well aware of this. After all, that is the
reason it has not been done before.

Still, a crazy amount of effort went into creating and maintaining rvm, rbenv
and the myriad of other tools we now have. I cannot help but wonder where we
would stand now had all of this instead been directed towards great packaging.

> You'd end up with at least 100 different packages, and you'll have to test
> each one of them. That's going to cost much more than a one-off campaign of
> $50000.

I am not quite so pessimistic. What I am daydreaming about would involve the
distributions and their package maintainers. They already ship ruby right now.
The packages are just not in optimal shape and oftentimes not up to date.

But one can surely build on the foundation already laid out by the
distributions and work with them to hand off some of the work.

Still, I know this would be a herculean task. And not only a technical
challenge, but a social one as well.

~~~
mpapis
system packages and maintainers in current day are not used to support mixing
multiple software with an easy separation like RVM does, they put everything
in one prefix like /usr and change only application suffix, it works well with
alternatives-update - but it’s static switching of ruby, what developers need
is runtime switching and clear separation of libraries per language, the lack
of clean separation also is bad when deploying servers that run multiple
versions of given language (not limiting to ruby)

also check the update with schedule -
[https://www.bountysource.com/fundraisers/489-rvm-2-0](https://www.bountysource.com/fundraisers/489-rvm-2-0)
\- "2 months: Work on building packages using RVM 2 (so it deprecates itself)"

------
moe
Rvm is still around?

I switched to rbenv years ago, never looked back.

~~~
eaurouge
I'm sorry, but why shouldn't RVM still be around? Did it suddenly become
obsolete the minute you switched to rbenv?

~~~
bobbyi_settv
RVM shouldn't still be around because of its user-hostile behavior of
modifying the user's dotfiles (.bashrc, etc.) on installation without warning
or permission.

This breaks other software in confusing ways. For example, I've had cases
where after installing it, I could not view man pages for any programs because
installing RVM modified broke my $MANPATH. In other cases, things that were
failing for other reasons started producing confusing errors due to RVM doing
sketchy things like replacing cd with a shell function.

~~~
FooBarWidget
> RVM shouldn't still be around because of its user-hostile behavior of
> modifying the user's dotfiles (.bashrc, etc.) on installation without
> warning or permission.

RVM tells the user very clearly that it has modified the user's dotfiles.

And how many people _do not_ want to modify the dotfile? Which user thinks,
"oooh, modifying dotfiles is so evil, I'll just type in this command _every
single time_ I open a terminal"?

At the end of the day, RVM just inserts a few lines to the dotfiles. What's
the problem with that?

Actually, chruby does not modify my dotfile for me, and I thought that
modifying the dotfile is optional. I figured I'll just manually source
chruby.sh every time I want to use it, just to experience how it's like. And
then I ran into issues like this:
[https://github.com/postmodern/chruby/issues/213](https://github.com/postmodern/chruby/issues/213)

Thanks but no thanks. I'd rather have the software modify my dotfile so that
it can give me a pleasant user experience.

> For example, I've had cases where after installing it, I could not view man
> pages for any programs because installing RVM modified broke my $MANPATH. In
> other cases, things that were failing for other reasons started producing
> confusing errors due to RVM doing sketchy things like replacing cd with a
> shell function.

Never seen these problems before. Have you reported these problems? Have they
been fixed in the latest version? If these problems are fixable then why throw
the baby out with the bath water?

As for replacing cd with a shell function: it's because it's one of the few
ways auto-switching can be implemented. They found in a user survey that 80%
of the users _want_ auto-switching, so who are they to say "no" to their
users?

What problems have you experienced because of this? chruby's auto.sh
implements the same functionality by installing itself into the shell's DEBUG
hook... but is that really any better?

~~~
bobbyi_settv
> Have they been fixed in the latest version?

I don't know. I don't use Ruby or RVM anymore.

> Which user thinks, "oooh, modifying dotfiles is so evil, I'll just type in
> this command every single time I open a terminal"?

I did. And it's not "every single time I open a terminal", it's "the once in a
blue moon that I need to work on a legacy Rails app".

> They found in a user survey that 80% of the users want auto-switching

Obviously people who choose to use RVM are going to be people who like the way
that RVM operates.

> If these problems are fixable then why throw the baby out with the bath
> water?

The bath water is the specific bugs I ran into. As you say, those may fixed
and aren't the point. The baby is the general practice of automatically
injecting things into dotfiles and messing with shell builtins. We should
throw that away because when it fails, it leads to "spooky action at a
distance" bugs that are hard to understand and that break totally unrelated
things (the user is in a shell session where they aren't doing anything
related to Ruby).

------
happypeter
RVM is already doing too much, and trying to do more. Sure there is no
looking-back since I switched to rbenv a year ago.

And yes, so now I need to install ruby in order to install ruby?!

------
anonymous
Or, they could just learn shell scripting. How much would that cost?

I do not understand why the[1] shell... which is a relatively small
language... is so difficult for people to learn.

If you can find the time to learn Ruby, what stops you from learning a shell?
What is the cost of ignoring it?

1\. Preferably something resembling the proposed POSIX standard which might
lend to portability. Bash is not necessarily the best choice unless every
server you will ever use will be GNU userland/Linux kernel.

~~~
mercurial
That's precisely the kind of dismissive comment I needed to read today. You
don't seem to have read the link, in which the author makes good points for
moving to Ruby, or think that somebody maintaining 20k of complex shell script
should actually "learn shell scripting". I'm sure the author is well-informed
about shell scripting. While it's certainly convenient in a pitch, it has
little support for unit-testing, error handling or other things which are
extremely useful to ensure a robust codebase.

~~~
anonymous
Well, since you seem to have insight as to the reasoning behind others'
choices, perhaps you could enlighten us how someone came up with the idea of
writing 20K lines of shell and passing it off to a community of Ruby
developers as a "command line tool"?

~~~
mercurial
Insight comes simply from having read the linked page. But at a guess, I'd say
it comes from "let's do something small and simple in bash" combined with a
bad case of incremental feature creep.

------
grogenaut
I would if RVM 1.0 didn't suck so much of my time away that I gave up and just
went with vagrant.

~~~
driverdan
Using vagrant in place of rvm is like killing a housefly with a hammer.
Vagrant is great if you want to setup the whole app environment but using it
just for rvm's functions is overkill.

~~~
grogenaut
yeah except try working on several projects where you have to use different
rubies with different c libraries and compilers. RVM can't handle that.
Vagrant can. rvm is like swatting at a housefly over and over and over and
over and over and over and over and not killing it and nothing happening.

------
nfoz
What is RVM?

~~~
agumonkey
I was affraid to ask, I always thought it was a codename for the Ruby Virtual
Machine ..

ps : I was conflicted I couldn't believe ruby's vm would be built on 20K lines
of bash. <relief/>

------
lightningstorm
Why we need rvm to install databases etc. when there is homebrew?

