Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rvm.io

Post reply on HN
Print view View original

51–60 of 72 posts

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

#51

Post by kisitu »

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 also mean that the project maintainers focus on their day jobs... the way Googlers hardly use their 20% time.

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

#52

Post by benatkin »

rurounijones wrote: post #50
benatkin wrote: post #48

Earlier quoted context omitted.

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

> 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/ 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 y…

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.

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

#53

Post by davidw »

oconnore wrote: post #33
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 n…

They should certainly be thanked, but it points to the larger problem that funding open source software in a stable, predictable way is hard.

When it's basically a charity, then it's probably going to get the axe pretty early on when there are financial troubles.

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

#54

Post by regularfry »

jrochkind1 wrote: post #11
smoyer wrote: post #10

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),…

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

The "bundle exec dance" is unnecessary. Bundler doesn't need to be more integrated, it needs to be less integrated. Half the mess people get into is because the boundaries between these systems break down.

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

#55

Post by regularfry »

hox wrote: post #38
mitchty wrote: post #29

Earlier quoted context omitted.

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.

I'm actually quite interested in how to fix that. The naive solution that springs to mind is sticking a local cache between my dev environment and the upstream sources, where I can control precisely what versions are available. Is that doable?

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

#56

Post by regularfry »

DanielKehoe wrote: post #42

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 proje…

I think RVM's played out. We can see the problems that approach comes with, so now we can move on to better things that don't have such high maintenance costs. That's the question we should be asking - why should a tool like this need funding to this extent?

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

#57

Post by regularfry »

halostatue wrote: post #36
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…

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

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

#58

Post by regularfry »

eaurouge wrote: post #30
jrochkind1 wrote: post #5

Earlier quoted context omitted.

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…

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 co…

> 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/rv.git

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

#59

Post by regularfry »

matthewmacleod wrote: post #7
pwelch wrote: post #3

Earlier quoted context omitted.

How does Docker fit in with Ruby version management software?

It removes the question of version management altogether by isolating an app's environment. Not too shabby an idea, especially now that Vagrant is available.

Bit of a sledgehammer to crack a nut, though. A useful tool nonetheless.

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

#60

Post by mh- »

regularfry wrote: post #55
hox wrote: post #38

Earlier quoted context omitted.

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.

I'm actually quite interested in how to fix that. The naive solution that springs to mind is sticking a local cache between my dev environment and the upstream sources, where I can control precisely what versions are available. Is that doable?

have a look at godep: https://github.com/kr/godep
Post reply on HN