3 ms·

The conversation at https://www.bountysource.com/fundraisers/489-rvm-2-0 https://www.bountysource.com/fundraisers/489-rvm-2-0 has a lot more meaning to it, prim

by ecaron 13y ago

The conversation at https://www.bountysource.com/fundraisers/489-rvm-2-0 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...

pwelch 13y ago
How does Docker fit in with Ruby version management software?
- tzaman 13y ago
  Simple, each ruby version sits in it's own container
- matthewmacleod 13y ago
  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.
  - regularfry 13y ago
    Bit of a sledgehammer to crack a nut, though. A useful tool nonetheless.
davidcelis 13y ago
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.
jrochkind1 13y ago
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 is to Rails as rbenv is to Sinatra. Sinatra is a lightweight framework whereas Rails is much more robust. Sometimes Sinatra just fits, and other times you'd be a fool to not go with Rails. I think people with complicated scenarios have had... mixed experiences with whether rvm really makes complex scenarios easy. I suspect many people with complex scenarios prefer a simple tool like rbenv or chruby (disclosure: I prefer chruby having worked with all three), which they can then figure out themselves how to invoke to do exactly what they need. 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!) But I suspect that the bulk of rvm users are not actually sophisticated users with complicated scenarios, but instead beginner users with fairly simple scenarios. For a variety of reasons. Becuase rvm is what you find when you google. Because rvm holds out the promise of not making you understand anything about what it's doing or anything about bash or shell environment, and having it Just Work (whether it fulfills that promise... especially in non-simple scenarios... there are mixed opinions. There are definitely some people who have moved from rvm to rbenv or chruby in fact as their environments have grown in complexity, and they had trouble figuring out how to get rvm to work in their environments. ). People try to be really sensitive not to insult rvm. And I've tried to be sensitive here, while still saying what I perceive. Lots of people like rvm, for sure. And rvm was first, and a huge boon compared to the no options that preceeded it. And nobody wants to be rude, or get into a fight. But people's sensitivity and desire to avoid controversy also means when you google around... you pretty much just find rvm, even though some (many? I don't know) have in fact moved from rvm to chruby and rbenv -- including sometimes moving as their environments become more complicated. I am not sure it's accurate to say that developers routinely find chruby or rbenv "quickly become inadequate" as environments and dependencies grow in complexity ('quickly'? really?).
- eaurouge 13y ago
  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 https://github.com/jf/rbenv-gemset
saidajigumi 13y ago
Docker is a bit orthogonal, IMO. One key problem these tools solve is getting a specified version of ruby onto a host at a granularity other that "whatever's in my distro's package repo". It's certainly possible to simplify matters and just use ruby-build[1] to normalize ruby acquisition. AFAICT, this is out of scope for Dockerfiles in recent incarnations. [1] https://github.com/sstephenson/ruby-build https://github.com/sstephenson/ruby-build
Legion 13y ago
> (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.

by ecaron 13y ago

pwelch 13y ago

How does Docker fit in with Ruby version management software?

tzaman 13y ago
Simple, each ruby version sits in it's own container
matthewmacleod 13y ago
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.
- regularfry 13y ago
  Bit of a sledgehammer to crack a nut, though. A useful tool nonetheless.

davidcelis 13y ago

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.

jrochkind1 13y ago

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 is to Rails as rbenv is to Sinatra. Sinatra is a lightweight framework whereas Rails is much more robust. Sometimes Sinatra just fits, and other times you'd be a fool to not go with Rails. I think people with complicated scenarios have had... mixed experiences with whether rvm really makes complex scenarios easy. I suspect many people with complex scenarios prefer a simple tool like rbenv or chruby (disclosure: I prefer chruby having worked with all three), which they can then figure out themselves how to invoke to do exactly what they need. 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!) But I suspect that the bulk of rvm users are not actually sophisticated users with complicated scenarios, but instead beginner users with fairly simple scenarios. For a variety of reasons. Becuase rvm is what you find when you google. Because rvm holds out the promise of not making you understand anything about what it's doing or anything about bash or shell environment, and having it Just Work (whether it fulfills that promise... especially in non-simple scenarios... there are mixed opinions. There are definitely some people who have moved from rvm to rbenv or chruby in fact as their environments have grown in complexity, and they had trouble figuring out how to get rvm to work in their environments. ). People try to be really sensitive not to insult rvm. And I've tried to be sensitive here, while still saying what I perceive. Lots of people like rvm, for sure. And rvm was first, and a huge boon compared to the no options that preceeded it. And nobody wants to be rude, or get into a fight. But people's sensitivity and desire to avoid controversy also means when you google around... you pretty much just find rvm, even though some (many? I don't know) have in fact moved from rvm to chruby and rbenv -- including sometimes moving as their environments become more complicated. I am not sure it's accurate to say that developers routinely find chruby or rbenv "quickly become inadequate" as environments and dependencies grow in complexity ('quickly'? really?).

eaurouge 13y ago
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 https://github.com/jf/rbenv-gemset

saidajigumi 13y ago

Docker is a bit orthogonal, IMO. One key problem these tools solve is getting a specified version of ruby onto a host at a granularity other that "whatever's in my distro's package repo". It's certainly possible to simplify matters and just use ruby-build[1] to normalize ruby acquisition. AFAICT, this is out of scope for Dockerfiles in recent incarnations. [1] https://github.com/sstephenson/ruby-build https://github.com/sstephenson/ruby-build

Legion 13y ago

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