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

11–20 of 72 posts

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

#11

Post by jrochkind1 »

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

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

#13

Post by 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...

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

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

#14

Post by twerquie »

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…

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

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

#15

Post by jrochkind1 »

llamataboot wrote: post #9

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.

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

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

#16

Post by dragonwriter »

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…

> 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 solutions (unlike the Python solution) attempt to manage versions that are not even from the same project, which naturally makes a single dictatorial-blessed solution problematic, as there is no dictator (or even central project) for the entire Ruby ecosystem, even if there is for the mainline interpreter.

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

#17

Post by 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

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

#19

Post by Legion »

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

> (from the link): To paraphrase Jonathan Jackson, RVM is to Rails as rbenv is to Sinatra.

I think that's overstating the difference quite a bit. If rbenv is Sinatra, RVM is a lot closer to Padrino than Rails.

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

This is exactly where I'm headed on the deployment side of things, but on the developer workstation side, where Rubyists are overwhelmingly Mac users, Docker isn't an option, if the developer wants to work natively rather than inside a VM.

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

#20

Post by mmgutz »

twerquie wrote: post #14
jrochkind1 wrote: post #11

Earlier quoted context omitted.

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

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

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.
Post reply on HN