3 ms·

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 certa

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 tool like RVM makes for a _more_ environment, not one that's easier to work with. Additionally, some of the schedule on that BountySource campaign makes me especially wary. If most of the code is rewritten in Ruby, presumably it would need to build/install Ruby during its own installation so it can be used afterwards. If the GUI relies on JRuby, it would need to build that during installation as well. Suddenly RVM becomes less easy to install.

rys 13y ago
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.

rys 13y ago

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.