Engine Yard's sponsorship of RVM is coming to an end • Hacker News Board

Re: Engine Yard's sponsorship of RVM is coming to an end

#31

Post by nonchalance » Tue, Oct 29, 2013, 2:17 AM UTC

jballanc wrote: post #17

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

Strictly speaking, they wrote:

> We are proud to employ and support contributors to such projects as Lithium, Travis CI, Rubinius and RailsInstaller. Check out the comprehensive list of open source projects we’re involved in below.

That fact hasn't changed (at least, not until they start firing people)

Re: Engine Yard's sponsorship of RVM is coming to an end

#32

Post by gexla » Tue, Oct 29, 2013, 2:26 AM UTC

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?

Re: Engine Yard's sponsorship of RVM is coming to an end

#33

Post by oconnore » Tue, Oct 29, 2013, 2:30 AM UTC

jballanc wrote: post #17

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

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.

Re: Engine Yard's sponsorship of RVM is coming to an end

#34

Post by [deleted] » Tue, Oct 29, 2013, 2:37 AM UTC

jballanc wrote: post #17

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

[deleted]

Re: Engine Yard's sponsorship of RVM is coming to an end

#35

Post by halostatue » Tue, Oct 29, 2013, 2:37 AM UTC

jrochkind1 wrote: post #5

ecaron wrote: post #2

The conversation at 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...

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…

Concur. I have steadily migrated from rvm to rbenv to chruby because the relative invasiveness of each solution has simplified my development life.

I have not yet been in a position to choose something for deployment, but I would lean heavily toward chruby (-ish; there's no need for it if you pay attention to how little it does, but it helps in development) and chgems (-ish; same reason) with bundler.

RVM should definitely not be used in production. I would generally argue against using rbenv in production at this point, too, as all you need to know is the right environment variables to have set for your application to make sure everything else is clean.

Re: Engine Yard's sponsorship of RVM is coming to an end

#36

Post by halostatue » Tue, Oct 29, 2013, 2:43 AM UTC

saidajigumi wrote: post #13

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…

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.

Re: Engine Yard's sponsorship of RVM is coming to an end

#37

Post by rys » Tue, Oct 29, 2013, 2:47 AM UTC

davidcelis wrote: post #4

ecaron wrote: post #2

The conversation at 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...

I actually think that the "RVM vs. rbenv vs. chruby" section of the BountySource page is pretty bad. There's almost no argument there, just that there are certain scenarios in which RVM "does a lot more to make handling [them] easy". What scenarios? In what situations would a "complex environment" or set of dependencies make RVM a choice that I'd "be a fool to not go with"? My experiences has been that a complicated…

The bootstrap for RVM 2.0 is something we're thinking about very seriously, to make sure it's handled properly and isn't brittle. As an rvm maintainer, one of the most frustrating things about working on it is how untestable and how brittle the installation (rvm + all build deps required to get a ruby built locally) can be.

It's a known problem and one of the current big design issues, especially because rvm is so complex today in what it's capable of on the user's behalf, so we plan to get that right first time as much as we can.

I agree with you on both of your points: the BountySource page is a bit hand wavy, although there's only so much room to spell out what we think our benefits are; that rvm can make life more complicated, not simpler.

I come to the project late in its life and I'm well aware it's a bit of a beast in many ways, so I can at least say that I'll be pushing Michal towards simplicity. It's one of the reasons 2.0 exists, rather than us heading towards 1.3 instead. It's just too hard to make large changes to 1.2 now, mostly because of the complexity inherent to being a shell program that works (mostly!) portably on the myriad OSes we now support.

Re: Engine Yard's sponsorship of RVM is coming to an end

#38

Post by hox » Tue, Oct 29, 2013, 2:58 AM UTC

mitchty wrote: post #29

dragonwriter wrote: post #16

Earlier quoted context omitted.

> I think that's true, and true in just about every language/environment, it's not unique to ruby, right? There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code. > I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be. As I understand, the competing Ruby…

This is the exact reason I'm migrating new things straight to go. Once I've gotten the updated blob (binary or script/whatever really) to where it needs to be. I'm done, at compile time I can deal with dependencies, don't need to have a metric ton of stat calls flying around from require and other nonsense. I'm getting to the point that the troubles encountered with Python/Perl/Ruby and dependency management has basi…

Yet go is a dependency nightmare! Dealing with more than one developer on a project with dependencies is incredibly difficult due to the insane decision to not support locking a dependency to a specific version.

Re: Engine Yard's sponsorship of RVM is coming to an end

#39

Post by TylerE » Tue, Oct 29, 2013, 3:23 AM UTC

nonchalance wrote: post #31

jballanc wrote: post #17

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

Strictly speaking, they wrote: > We are proud to employ and support contributors to such projects as Lithium, Travis CI, Rubinius and RailsInstaller. Check out the comprehensive list of open source projects we’re involved in below. That fact hasn't changed (at least, not until they start firing people)

It could easily mean they're no longer letting them work on their projects on the clock, though.

Re: Engine Yard's sponsorship of RVM is coming to an end

#40

Post by yerhot » Tue, Oct 29, 2013, 3:27 AM UTC

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.