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

21–30 of 72 posts

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

#21

Post by daleharvey »

mmgutz wrote: post #20
twerquie wrote: post #14

Earlier quoted context omitted.

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

That is not how node / npm works, it specifically solves this problem, each module gets its own version of its dependancies

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

#22

Post by rubiquity »

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.

I agree about npm. Having the individual node_modules fixes a lot of dependency management issues. That said, I'm not a fan of Nodd but if I could steal two things from them it would npm and Isaac.

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

#23

Post by nadaviv »

mmgutz wrote: post #20
twerquie wrote: post #14

Earlier quoted context omitted.

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

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?

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

#24

Post by schmichael »

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

I was a full time Python developer for years and can attest that virtualenv + ... easy_install? pip? wat?! scared off a lot of marginal developers.

It's a good cautionary tale for any language/platform that wants to claim Ease of Use and Low Barrier to Entry (as it seems both Python and Ruby do).

Hopefully Python 3.4 bundling virtualenv and pip will ease the pain, but it's still a shame these otherwise easy to use scripting languages ended up with such complex sandboxing mechanisms for even trivial use cases (e.g.: my simple script has 1 third party dependency).

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

#26

Post by llamataboot »

jrochkind1 wrote: post #15
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?

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

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

#27

Post by smoyer »

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…

Yes ... I specifically said I had similar issues with Java because I didn't want to appear to be targeting Ruby. I also know python, and I've gotten stuck with PIP a couple times. I'd consider myself an expert with Maven, and I don't tend to have issues with that (anymore). And I think the model used for Maven (and Ivy) is perfect (a central repository of artifacts by GAV).

But I've seen people give up due to the learning curve of learning Maven, and I agree that this is a hard problem in general. I think (as noted below) that it's an even harder problem for scripting languages that deliver packages via source ... and I don't have a solution to offer.

Perhaps the best thing we can do is help each other out with the tools we're comfortable with? An apprenticeship program?

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

#28

Post by philwelch »

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

Dependency hell isn't a language issue, and the concept of RubyGems or any other language-specific dependency management system is fundamentally broken because it's impossible to manage all your dependencies with it. You resort to nested dependency management--i.e. RVM to manage your Ruby installations, then Bundler to manage the gems inside those installations, with some patchwork for the MySQL client your mysql2 gem has a dependency on (but can't declare or guarantee in RubyGems) and it works...kind of. For now.

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

#29

Post by mitchty »

dragonwriter wrote: post #16
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, 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 basically made me go, ok fine, i'll go back to c this is getting ridiculous.

That plus clang has made me happy.

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

#30

Post by eaurouge »

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…

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

Post reply on HN