

Engine Yard's sponsorship of RVM is coming to an end - whiteotter
http://rvm.io/

======
smoyer
I hate (yes, it's that strong a word) the problems related to versioning in
Ruby ... and even with RVM, you have to figure out which gems are compatible.
My solution is to get rid of my Ruby applications. I'm not a Ruby developer,
and my career path isn't likely to afford me the time to really learn it.

I'm a Java developer, and we have our own version of dependency hell (that
I've learned to avoid and/or navigate), so I'm not trolling, but rather wanted
to point out that often issues like dependency management (there are others)
simply cause marginal developers to leave.

~~~
jrochkind1
> often issues like dependency management (there are others) simply cause
> marginal developers to leave.

I think that's true, and true in just about every language/environment, it's
not unique to ruby, right? Dependency management often causes marginal
developers to leave, in many langauges/environments.

Dependency management itself has gotten a _lot_ better in ruby -- bundler is
pretty great.

But multiple ruby version management is still a mess. I wish ruby would have a
single dictatorial-blessed solution to multiple ruby version management, like
I understand python to be.

And even bundler isn't perfect, for sure -- I wish bundler was more integrated
with rubygems, which would for instance make the `bundle exec` dance
unneccesary.

Interestingly, both of these issues, as I see it, are related to the
decentralized open source nature of the ruby ecosystem. Which has plusses and
minuses.

(And both dependency management and multiple version management can be hell in
Java, for sure. I am not a Java developer, and the most common barrier I run
into when trying to deal with Java is... maven. And last time I had to run
multiple versions of the JVM on one machine, it was hell. I hope it's gotten
better.)

~~~
twerquie
> I think that's true, and true in just about every language/environment

Agreed, although it seems as if nodejs may have solved most of the hard
problems in this area by way of their unique require() module loader and the
design of npm. After learning it, I wish every package manager worked that
way.

~~~
mmgutz
Ran into same issues with nodejs. If one of your dependencies use libxy 1.2
and your app depends on libxy 1.4, you have to be careful which one gets
loaded first and hope one is compatiblew with the ohter. Good luck if the APIs
are different. NPM _seems_ to solve the problem but it really doesn't.

~~~
nadaviv
This shouldn't be an issue at all. Your app would get libxy 1.4, and your
dependency would get libxy 1.2. It shouldn't matter which is loaded first, and
unless those modules somehow store something globally, they shouldn't conflict
in any way.

npm does solve the "multiple versions of a library are used by different
packages", unless that libxy you were using did something fishy. Can you give
more details?

------
jballanc
So Engine Yard ends their support of JRuby in 2012. Then, just a few weeks
ago, they end support for Rubinius. Now, they'll be ending support for RVM
next week... A shift in strategy? Financial troubles? Either way, it seems
they need to update their "Engine Yard Loves Open Source" page:
[https://www.engineyard.com/community/open-
source](https://www.engineyard.com/community/open-source)

~~~
oconnore
Oh how fickle you are. A company that supports an open source project out of
pocket for two years now doesn't love open source because they have moved onto
other things? Over time, technologies change, stabilize, and/or become
obsolete, expecting them to support one project forever is silly and boring.

How about: dear Engine Yard, thanks for 730 days of open source love, can't
wait to see where you invest your time next.

~~~
jballanc
I don't disagree, which is why I'm wondering if this is a case of not having
enough money to continue supporting these projects, or a case of seeing the
momentum or the need for support in open source changing to something new. So
far, though, I've only seen Engine Yard drop support for projects. If,
tomorrow, they announced that they were starting to support a handful of Go or
node.js projects, then I think we'd all have a much different view on this
news.

------
DanielKehoe
Here we go again. We've got companies building skytowers using the steel and
concrete we fund with bake sales. Our most important open source projects are
dependent on corporate philanthropy that can disappear overnight.

We can debate the merits of RVM/chruby/rbenv yet all agree that open source
version management projects are essential infrastructure for Ruby. Sure, we're
grateful that EY funded RVM (and other projects) for so long. But what now?

I contributed $50 to the RVM Bountysource campaign.But a one-shot charitable
fundraiser is a slim reed on which to sustain a project like this. Tens of
thousands of developers use RVM. And the companies they work for spend
millions to develop businesses that could not be be built without the
infrastructure provided by open source projects such as RVM. It's skytowers
funded by bake sales.

~~~
rurounijones
Welp there are people trying to address this,
[https://www.gittip.com/](https://www.gittip.com/) for instance.

~~~
benatkin
Gittip is chump change.

The amount of money raised so far for rvm's current crowdfunding is about the
amount that the top receiver on Gittip might get in 20 weeks.
[https://www.gittip.com/](https://www.gittip.com/)

You say Gittip is trying. That's true, but I think they slipped into a slow
growth pattern months ago. At its current rate it would take years for it to
be a viable way of funding more than a handful of open source hackers.

~~~
rurounijones
> The amount of money raised so far for rvm's current crowdfunding is about
> the amount that the top receiver on Gittip might get in 20 weeks.
> [https://www.gittip.com/](https://www.gittip.com/)

That is not a technical problem, that is a social one. The OP said

> But a one-shot charitable fundraiser is a slim reed on which to sustain a
> project like this.

And he is correct, the gittip style is probably better for long-term but faces
problems as you pointed out, although again, I do not think any of them are
technical in nature.

(Probably the biggest problem being the complete lack of companies on gittip
et al and the feeble amounts, in terms of companies' budgets anyway.)

~~~
benatkin
This supports my point. My point is that Gittip is irrelevant and there's no
reason to believe it will become relevant. If it were a technical problem and
yet had reached its current level of success, I would think that if they fixed
their technical problems, it might become relevant. Since it's a non-technical
problem (social problem, positioning problem), how to fix it is unknown. The
quickest path would very likely involve tearing the whole thing down and
starting over again.

------
saidajigumi
The RVM 2.0 plan doc[1] doesn't seem touch on one of my serious problems with
RVM: how will it implement ruby environment integration with the shell?
Specifically, I've found that RVM's use of shell functions is horribly brittle
in some important cases. So much so that I've banished it from all
environments that I control (to date, in favor of rbenv and/or ruby-build).

For comparison, rbenv simply needs ~/.rbenv/bin and ~/.rbenv/shims added to
$PATH. I'm all for magic when it's seamless[2], but I've not found that to be
the case with RVM. Using PATH makes it quite clear in any given execution
context whether rbenv is managing a command.

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

[2] By "magic", I mean underlying complexity that creates practical
simplicity.

~~~
halostatue
As I said elsethread, I haven't yet considered production, but I just switched
to chruby for my development environment rather than rbenv. I still use ruby-
build when I need (I just needed a version not supported by ruby-install), but
I have switched wholesale to chruby, and having found chgems in researching a
different answer, I may look at using that as well.

chruby really is the simplest possible thing you can do to solve this problem,
and in combinations with chgems, it solves isolation better than RVM does
without the brittleness of the shims that rbenv has (ultimately why I moved
away from rbenv). Installs are substantially easier with ruby-install and/or
ruby-build, although RVM is _probably_ better at this part in general. Extract
that out from RVM and I'd consider using it.

~~~
regularfry
I'd argue that you don't need _any_ of rvm/rbenv/chruby in production.

~~~
halostatue
I'd agree. Something as simple as chruby makes having multiple
interpreter/gemset versions easily usable from something like cron without
introducing a lot more overhead, though, or having to remember to put all the
variables &c. in place everywhere you need them.

------
yerhot
First time I've ever felt compelled to actually leave a comment on HN. And
full disclosure - I work at Engine Yard.

Thanks Brian Shirai, Michael Papis, Wayne Sequin, Kirk, Evan, Dr. Nic, etc...
and Engine Yard for the support of all these projects. Getting to working with
these gents has been one of the highlights of the last few years for me.

------
gexla
Go was born in Google. Docker was born in dotCloud. Each of these projects are
really "moving the chains" in my world. Perhaps EngineYard is looking at this
and thinking of ways they could focus on something which could be equally as
important.

Also, I just went to the EngineYard web site and Ruby isn't mentioned any more
prominently than the other ecosystems it supports. Why keep supporting
projects in the Ruby ecosystem when you have moved into a much wider world?

------
ecaron
The conversation at
[https://www.bountysource.com/fundraisers/489-rvm-2-0](https://www.bountysource.com/fundraisers/489-rvm-2-0)
has a lot more meaning to it, primarily why RVM vs. rbenv vs. chruby all
deserve to exist.

As for me and mine, I'm in the land of docker now...

~~~
jrochkind1
For those curious, what that page by rvm authors suggests is that:

> _Tools like rbenv or chruby can work well in simple scenarios, especially if
> you’re very skilled with the Unix shell. However, as environments and
> dependencies grow in complexity, these tools quickly become inadequate. RVM
> seems more “complicated” because it does a lot more to make handling these
> scenarios easy._

> _To paraphrase Jonathan Jackson, RVM is to Rails as rbenv is to Sinatra.
> Sinatra is a lightweight framework whereas Rails is much more robust.
> Sometimes Sinatra just fits, and other times you 'd be a fool to not go with
> Rails._

I think people with complicated scenarios have had... mixed experiences with
whether rvm really makes complex scenarios easy. I suspect many people with
complex scenarios prefer a simple tool like rbenv or chruby (disclosure: I
prefer chruby having worked with all three), which they can then figure out
themselves how to invoke to do exactly what they need.

It may be that some people with complex scenarios prefer rvm. It would be
interesting to hear from them. (for real! I'd be interested!)

But I suspect that the bulk of rvm users are not actually sophisticated users
with complicated scenarios, but instead beginner users with fairly simple
scenarios. For a variety of reasons. Becuase rvm is what you find when you
google. Because rvm holds out the promise of not making you understand
anything about what it's doing or anything about bash or shell environment,
and having it Just Work (whether it fulfills that promise... _especially_ in
non-simple scenarios... there are mixed opinions. There are definitely _some_
people who have moved from rvm to rbenv or chruby in fact _as_ their
environments have grown in complexity, and they had trouble figuring out how
to get rvm to work in their environments. ).

People try to be really sensitive not to insult rvm. And I've tried to be
sensitive here, while still saying what I perceive. Lots of people like rvm,
for sure. And rvm was first, and a huge boon compared to the no options that
preceeded it. And nobody wants to be rude, or get into a fight. But people's
sensitivity and desire to avoid controversy also means when you google
around... you pretty much just find rvm, even though _some_ (many? I don't
know) have in fact moved from rvm to chruby and rbenv -- including sometimes
moving as their environments become more complicated.

I am not sure it's accurate to say that developers routinely find chruby or
rbenv "quickly become inadequate" as environments and dependencies grow in
complexity ('quickly'? really?).

~~~
eaurouge
_It may be that some people with complex scenarios prefer rvm. It would be
interesting to hear from them. (for real! I 'd be interested!)_

I like the sandboxed gemsets that RVM provides. It seems you can do something
similar with rbenv if you use this add-on [1].

I've also used the RVM gem programmatically to install gems on the fly in an
isolated environment, and optionally tear the whole thing down when the
program completes.

1\. [https://github.com/jf/rbenv-gemset](https://github.com/jf/rbenv-gemset)

~~~
regularfry
> I like the sandboxed gemsets that RVM provides. It seems you can do
> something similar with rbenv if you use this add-on [1].

There are many ways to skin that cat. It's not a particularly difficult
problem to solve. I wrote one of my own[0] - it's worth doing that yourself to
understand how it works, I'd say.

> I've also used the RVM gem programmatically to install gems on the fly in an
> isolated environment, and optionally tear the whole thing down when the
> program completes.

That's quite an interesting approach - is this for continuous integration?

[0]
[https://github.com/regularfry/gemenv.git](https://github.com/regularfry/gemenv.git),
[https://github.com/regularfry/rv.git](https://github.com/regularfry/rv.git)

------
calineczka
Some time ago I blogged about how we stopped using RVM in production:
[http://blog.arkency.com/2012/11/one-app-one-user-one-
ruby/](http://blog.arkency.com/2012/11/one-app-one-user-one-ruby/) . Many
people here said that RVM might be over-complicated for the simplest cases and
I think in production when there is only one app is the most simple usecase
that you can get and RVM is overkill in such situation. In development however
RVM is awesome, especially when you are a contractor or freelancer or you work
on multiple open source ruby projects and gems and must switch between ruby
versions often.

Michał Papis, the current maintainer is a great person and I wish him best
luck in funding the project. If you want to meet him in person, he will
probably be at wroc_love.rb 2014 conference (
[https://twitter.com/wrocloverb](https://twitter.com/wrocloverb) ) . Check out
what he learned so far on working with RVM1 and what are the plans for RVM2:
[http://www.youtube.com/watch?v=wN-
iIC3S1ZM](http://www.youtube.com/watch?v=wN-iIC3S1ZM) . I remember that some
of the ideas for RVM2 were invented after our Ruby User Group meeting at 3
a.m. in the night, when we were trying to think about most science fiction
approaches to RVM such as even a client server architecture. That was a crazy
night :)

The biggest problem with RVM1 is that it is written in shell and even if there
are people from Ruby community that would like to support this project, their
skills are in Ruby language, not bash or zsh, etc. There are plenty of people
who would like to help maintaining RVM but they just hit the wall when they
see the amount of bash code in the project.

------
llamataboot
Add me to the list of people that would like more information about the rvm vs
rbenv question. I switched to rbenv a few months ago because I wanted
something to manage my ruby version only, not gemsets and the rest and I use
bundler and shims now.

~~~
jrochkind1
What sort of more information would you like? You mean more and different
people's opinions/experiences? or something else?

~~~
llamataboot
Yes more opinions :) I'm a relatively new Ruby developer so tend to swing
whichever way the last good article I read leads me towards, so more is always
better

------
wat29
I wish people wouldn't freak out so much about this. RVM is pretty mature at
this point, and there are some really great alternatives like rbenv and
chruby.

------
knodi
Is gem set management still required if using bundler?

~~~
SingAlong
Not required if you use bundler.

But after you are done with the project, there is no easy way to delete the
gems that the project uses all at once.

~~~
crymer11
If you bundle install with the `--path` flag (which you should), you can
specify the location the gems will be installed (typically something like
`--path vendor`) which gives you the ability to easily remove the gems the
project uses all at once.

Coupled with `bundle package` which stores all the .gem files in vendor/cache,
you can ensure that your application always has its gem dependencies
available.

Here's a great article with more information about all the above:
[http://ryan.mcgeary.org/2011/02/09/vendor-everything-
still-a...](http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-
applies/)

