5 ms·

You are entitled to your opinion, but as other commenter pointed out, rvm was created for production. > hey exist to allow developers on Macbooks to sync their

by irahul 13y ago

You are entitled to your opinion, but as other commenter pointed out, rvm was created for production. > hey exist to allow developers on Macbooks to sync their version of Ruby with whatever is packaged in the Linux distro or BSD variant that runs in production. Or to allow developers who run ubuntu to develop multiple projects which need conflicting versions of the Gem and interpreters seamlessly. Also, I sometimes deploy multiple projects on same production box where the 2 might need different interpreters, and they almost always need separate gemsets. I can manage the interpreters and LOAD_PATH manually, but then I will end up creating an unholy mess which will somewhat resemble rvm. I am curious. What are your reasons for "rvm doesn't belong in production"?

alrs 13y ago
The best example of why the rvm model fails on the dev side is nokogiri. Yeah, sure, you can have multiple versions of Ruby and the Nokogiri gem on the same box. libxml2, borrowed from the GNOME project, is the C library that is doing all of the heavy lifting underneath. If the version of libxml2 on your dev machine is different than the version in prod, it doesn't much matter if you've got the same version of Ruby and the same version of Nokogiri. Use Vagrant. You will get a complete Linux VM for each different project that will match up perfectly with whatever the prod environment looks like.
- irahul 13y ago
  Do you deploy with Vagrant? I think container might be the way forward, but I am not convinced, and I don't deploy Vagrant to production(containers might be the future for deployment but Vagrant in it's current state isn't). I don't use vagrant in production because I use a Ubuntu box for development and rvm/bundler, virtualenv/pip...cover my needs for maintaining different and isolated dev environments.
  - alrs 13y ago
    No, I don't deploy with Vagrant. Nor would I. Use Vagrant to spin up Linux VMs locally so that you can have a dev environment that matches production.
    - irahul 13y ago
      Yes, but that won't solve when I have 2 applications deployed on the same production box. rvm solves it.
      - alrs 13y ago
        "Solves" in the same vein of "There, I Fixed It." http://thereifixedit.blogspot.com/ http://thereifixedit.blogspot.com/
        irahul 13y ago
        I don't see any point in conversing any further since you are being intentionally obtuse. apt-get doesn't help me with different projects using different ruby interpreters and isolated gemsets(and it shouldn't); rvm does. I deploy multiple applications to the same production box, rvm solves multiple interpreters and gemsets, I use it. Your diatribe about package management and rvm is responding to imaginary arguments. Also, package management doesn't keep up with Ruby releases and I would rather install from rvm then packaging my own and having a separate apt server. And as pointed out many times, it's not just about the interpreters but isolating gems.
        alrs 13y ago
        Addressed: https://news.ycombinator.com/item?id=6505227 https://news.ycombinator.com/item?id=6505227 I don't work in a Ruby shop anymore, but I'd look at Bundler if I was looking to manage multiple gemsets on the same installation. As I point out in the above thread, maintaining multiple gemsets on the same machine is an antipattern that points to technical debt. Ruby 1.8 is over. EOL. You need to port everything forward or suffer the consequences.
        irahul 13y ago
        > Addressed: https://news.ycombinator.com/item?id=6505227 https://news.ycombinator.com/item?id=6505227 False dichotomy. There is no technical debt. Both Ruby 1.9.3 and Ruby 2 are functional and used in production. It will take some time to totally move to 2, and when that happens, there will be applications on different release versions of 2. I don't want to wait for os packaging to use a new ruby release, and I don't want to be forced by the packaging to use a particular version(older or newer). > I don't work in a Ruby shop anymore, but I'd look at Bundler Um. I use Bundler along with rvm. > maintaining multiple gemsets on the same machine is an antipattern that points to technical debt. Having a restriction of not more than one app on one machine is as stupid as it gets.
- xentronium 13y ago
  FWIW, current nokogiri 1.6.0 bundles and compiles its own libxml.
alrs 13y ago
As for rvm in production: Superior package management is the reason that small teams of ops people can manage huge deployments. In the bad old days of early Linux or traditional UNIX one had to hand-build and deploy those dozens of libraries that go scrolling by when you "apt-get install libxml2". Worse, the only way to really figure out the dependency tree was a recursive operation that involved picking a library, downloading it, attempting to build it, waiting for it to fail, figuring out what other library was missing, downloading that library, attempting to build it, waiting for it to fail, figuring out what library was missing... Inevitably, the grad student that wrote one of the libraries somewhere in this dependency soup would have moved on, and the web page at http://morlock.iscs.random.edu/~gradguy http://morlock.iscs.random.edu/~gradguy would disappear. The next step would be to fire up an ftp client and start digging around sunsite.unc.edu and some surviving yggdrasil mirror in Australia with a banner that said "PLEASE DO NOT USE THIS SERVER IF YOU ARE OUTSIDE OF AU/NZ, WE ARE PAYING $10 PER MEGABYTE ACROSS INTERNATIONAL LINKS." Once the software was compiled you then had to subscribe to every mailing list for each piece of software and keep an eye for security notices. If the project didn't have a mailing list you had to keep an eye on the relevent USENET groups where something might get mentioned. If the project had neither you just had to visit the FTP site every so often and see if there was a new version. If the project had a changelog you could read that and hopefully make a decision as to whether it was necessary to upgrade. If it didn't have a changelog you had to diff the old source and the new source and try to figure out what the implications were. Package management put an end to this insanity. The Linux Filesystem Standard was an important part of this, as well. rvm turns its back on 20 years of progress and goes takes us back to ad-hoc what-the-fuckery. A proper Linux distribution is an exercise in distributed responsibility. Instead of saddling every sysadmin in the world with the individual responsibility of making all of these decisions, expertise is allowed to accrete with the individual packagers. The operator evaluates the quality of the distribution and trusts the packagers to do the right thing.
- FooBarWidget 13y ago
  So you're saying that using distro packages saves the sysadmin a lot of work because a lot of maintenance will be offloaded to the distro maintainers. Fair enough. So what do you do if the specific Ruby version you need isn't packaged? What's that I hear? Compile from source? How exactly is that any better than RVM? Every single piece of criticism you shouted against RVM applies just as much, if not MORE, to tarball compilation.

by irahul 13y ago

alrs 13y ago

The best example of why the rvm model fails on the dev side is nokogiri. Yeah, sure, you can have multiple versions of Ruby and the Nokogiri gem on the same box. libxml2, borrowed from the GNOME project, is the C library that is doing all of the heavy lifting underneath. If the version of libxml2 on your dev machine is different than the version in prod, it doesn't much matter if you've got the same version of Ruby and the same version of Nokogiri. Use Vagrant. You will get a complete Linux VM for each different project that will match up perfectly with whatever the prod environment looks like.

irahul 13y ago
Do you deploy with Vagrant? I think container might be the way forward, but I am not convinced, and I don't deploy Vagrant to production(containers might be the future for deployment but Vagrant in it's current state isn't). I don't use vagrant in production because I use a Ubuntu box for development and rvm/bundler, virtualenv/pip...cover my needs for maintaining different and isolated dev environments.
- alrs 13y ago
  No, I don't deploy with Vagrant. Nor would I. Use Vagrant to spin up Linux VMs locally so that you can have a dev environment that matches production.
  - irahul 13y ago
    Yes, but that won't solve when I have 2 applications deployed on the same production box. rvm solves it.
    - alrs 13y ago
      "Solves" in the same vein of "There, I Fixed It." http://thereifixedit.blogspot.com/ http://thereifixedit.blogspot.com/
      - irahul 13y ago
        I don't see any point in conversing any further since you are being intentionally obtuse. apt-get doesn't help me with different projects using different ruby interpreters and isolated gemsets(and it shouldn't); rvm does. I deploy multiple applications to the same production box, rvm solves multiple interpreters and gemsets, I use it. Your diatribe about package management and rvm is responding to imaginary arguments. Also, package management doesn't keep up with Ruby releases and I would rather install from rvm then packaging my own and having a separate apt server. And as pointed out many times, it's not just about the interpreters but isolating gems.
        alrs 13y ago
        Addressed: https://news.ycombinator.com/item?id=6505227 https://news.ycombinator.com/item?id=6505227 I don't work in a Ruby shop anymore, but I'd look at Bundler if I was looking to manage multiple gemsets on the same installation. As I point out in the above thread, maintaining multiple gemsets on the same machine is an antipattern that points to technical debt. Ruby 1.8 is over. EOL. You need to port everything forward or suffer the consequences.
        irahul 13y ago
        > Addressed: https://news.ycombinator.com/item?id=6505227 https://news.ycombinator.com/item?id=6505227 False dichotomy. There is no technical debt. Both Ruby 1.9.3 and Ruby 2 are functional and used in production. It will take some time to totally move to 2, and when that happens, there will be applications on different release versions of 2. I don't want to wait for os packaging to use a new ruby release, and I don't want to be forced by the packaging to use a particular version(older or newer). > I don't work in a Ruby shop anymore, but I'd look at Bundler Um. I use Bundler along with rvm. > maintaining multiple gemsets on the same machine is an antipattern that points to technical debt. Having a restriction of not more than one app on one machine is as stupid as it gets.
xentronium 13y ago
FWIW, current nokogiri 1.6.0 bundles and compiles its own libxml.

alrs 13y ago

As for rvm in production: Superior package management is the reason that small teams of ops people can manage huge deployments. In the bad old days of early Linux or traditional UNIX one had to hand-build and deploy those dozens of libraries that go scrolling by when you "apt-get install libxml2". Worse, the only way to really figure out the dependency tree was a recursive operation that involved picking a library, downloading it, attempting to build it, waiting for it to fail, figuring out what other library was missing, downloading that library, attempting to build it, waiting for it to fail, figuring out what library was missing... Inevitably, the grad student that wrote one of the libraries somewhere in this dependency soup would have moved on, and the web page at http://morlock.iscs.random.edu/~gradguy http://morlock.iscs.random.edu/~gradguy would disappear. The next step would be to fire up an ftp client and start digging around sunsite.unc.edu and some surviving yggdrasil mirror in Australia with a banner that said "PLEASE DO NOT USE THIS SERVER IF YOU ARE OUTSIDE OF AU/NZ, WE ARE PAYING $10 PER MEGABYTE ACROSS INTERNATIONAL LINKS." Once the software was compiled you then had to subscribe to every mailing list for each piece of software and keep an eye for security notices. If the project didn't have a mailing list you had to keep an eye on the relevent USENET groups where something might get mentioned. If the project had neither you just had to visit the FTP site every so often and see if there was a new version. If the project had a changelog you could read that and hopefully make a decision as to whether it was necessary to upgrade. If it didn't have a changelog you had to diff the old source and the new source and try to figure out what the implications were. Package management put an end to this insanity. The Linux Filesystem Standard was an important part of this, as well. rvm turns its back on 20 years of progress and goes takes us back to ad-hoc what-the-fuckery. A proper Linux distribution is an exercise in distributed responsibility. Instead of saddling every sysadmin in the world with the individual responsibility of making all of these decisions, expertise is allowed to accrete with the individual packagers. The operator evaluates the quality of the distribution and trusts the packagers to do the right thing.

FooBarWidget 13y ago
So you're saying that using distro packages saves the sysadmin a lot of work because a lot of maintenance will be offloaded to the distro maintainers. Fair enough. So what do you do if the specific Ruby version you need isn't packaged? What's that I hear? Compile from source? How exactly is that any better than RVM? Every single piece of criticism you shouted against RVM applies just as much, if not MORE, to tarball compilation.