5 ms·

It really is very good advice, and installing Ruby/RubyGems through the package manager is almost never a good idea (especially on Debian-based distros) for sev

by samdk 16y ago

It really is very good advice, and installing Ruby/RubyGems through the package manager is almost never a good idea (especially on Debian-based distros) for several reasons. Ruby is a language that moves very, very quickly. On "cutting-edge" distros like Fedora and Arch it's not nearly as much of an issue, but not having to wait to get new language versions is very convenient. More importantly, though, is that the version of RubyGems distributed through Debian's (and Debian descendents like Ubuntu's) package repositories is crippled. Gem normally includes a very important command called 'gem update --system' that lets you upgrade gem itself. The opinion of the Debian package maintainers is that all upgrades should be handled through the package manager. This makes sense from a system administration perspective, but it's a huge pain when you're trying to do Ruby development, because important gems like Rails often require a fairly new version of RubyGems. (And Ruby libraries get updated much more frequently than the language itself.) For the above reasons, doing Ruby stuff on Debian/Ubuntu without using RVM is a huge pain. Even if you manage to get everything working, an update to gem or something else may break it a week later. While RVM isn't as essential on other distros (like Fedora, which I did Ruby dev on for a long time before learning about RVM), it's still massively convenient. You can ensure that you have a consistent development environment across computers and operating systems (which I find is especially useful when deploying to a server, since I use different Linux distros for everyday use than I do for hosting things), you can easily switch between Ruby versions (I have one project still on 1.8.7, and I do the rest of my stuff on 1.9.x--switching between them is as simple as typing rvm $VERSION), and it deals with all of the icky bits of managing multiple versions of gems (to go with your multiple versions of Ruby) for you. RVM is awesome, and makes lots of the headaches that surround Ruby development go away. Use it.

zppx 16y ago
> "Ruby is a language that moves very, very quickly." and later > "This makes sense from a system administration perspective, but it's a huge pain when you're trying to do Ruby development" It's a developer's world. Having been a Rails programmer working on some internals projects in the company that I used to work, I like both Ruby and Rails. But now I'm' working as an operations guy (ie, a sysadmin) in a new company, we came short of adopting redmine and maybe opening the road for more ruby and rails software to be used, we already use puppet and so every sysadmin now knows ruby, so it would be good to include some more ruby to internal use, but it was just a pain in the ass to maintain the rails-based infrastructure, in both Debian and CentOS, the distributions that we use. Fedora and Arch is not used in the servers, so it cannot be used. This is old, and just touches one aspect of the problems (shared hosting, which I do not deal with), but it does have some good rants, specially the point 2 of "How it could be better": http://blog.dreamhost.com/2008/01/07/how-ruby-on-rails-could-be-much-better/ http://blog.dreamhost.com/2008/01/07/how-ruby-on-rails-could...
alrs 16y ago
I feel very strongly about this. I've done good business coming in and mopping up messes after people that attempt to deploy applications this way. I'll follow up after I'm done with Christmas celebrations, but to think that a random hodgepodge of flavor-of-the-week deploy scripts slapped together by a webdev and scraped from github are somehow better or more maintainable than the collaborative output of some of the world's smartest and most committed developers is flatly-ridiculous. Follow http://planet.debian.org http://planet.debian.org for a week and tell me these people don't know what they're doing.
- samdk 16y ago
  RVM is hardly a 'random hodgepodge of flavor-of-the-week deploy scripts'. RVM is widely used throughout the Ruby community and for good reason. I'm really not interested in getting into some back-and-forth flamewar about this. (There's been plenty enough of that on the Debian mailing lists and elsewhere already.) I trust that the people maintaining Debian are very smart and do, in general, know what they're doing. But I don't trust that the people maintaining Debian know how to deploy Ruby/Rails better than the people in the Ruby/Rails community.
  - zppx 16y ago
    I can see the value of RVM for developers, running the same code against various gemsets and versions of Ruby, I used it this way, but not for deployment, why not simply compile everything necessary by hand, install the necessary gems, say ruby 1.9.2 with rails 3.0.3 and some other gems, and them use the result to chroot personalized deploys (or containerize them) instead of installing various versions of ruby with one shell script? EDIT: Well, since you cannot answer in this thread feel free to answer in my first comment in this thread above if you wish. EDIT2: I found this article about the matter, I found it to be good, I agree with him in the large picture: http://rcrowley.org/articles/dependencies.html http://rcrowley.org/articles/dependencies.html
    - samdk 16y ago
      I'm not really sure I understand your question. RVM is a tool that can do all of that for me, and it's used and vetted by a large community. I don't know why I wouldn't use RVM. RVM automates the compilation step. I'm not sure why I'd want to do that by hand instead. Gem installation is done on a per-app basis using bundler[0] or RVM's gemsets, so the gems for each application are kept separate anyway. Running different applications on different versions of Ruby at once is also easy with project-level rvmrc files. And if for whatever reason you want different RVM installs for different users that's easy too: RVM only installs for a single user by default. Now, granted, I don't do anything like run a shared hosting service, and there may be cases where RVM lacks the flexibility to do what's required, but I've never run into them. [0] http://rubygems.org/gems/bundler http://rubygems.org/gems/bundler

by samdk 16y ago

zppx 16y ago

> "Ruby is a language that moves very, very quickly." and later > "This makes sense from a system administration perspective, but it's a huge pain when you're trying to do Ruby development" It's a developer's world. Having been a Rails programmer working on some internals projects in the company that I used to work, I like both Ruby and Rails. But now I'm' working as an operations guy (ie, a sysadmin) in a new company, we came short of adopting redmine and maybe opening the road for more ruby and rails software to be used, we already use puppet and so every sysadmin now knows ruby, so it would be good to include some more ruby to internal use, but it was just a pain in the ass to maintain the rails-based infrastructure, in both Debian and CentOS, the distributions that we use. Fedora and Arch is not used in the servers, so it cannot be used. This is old, and just touches one aspect of the problems (shared hosting, which I do not deal with), but it does have some good rants, specially the point 2 of "How it could be better": http://blog.dreamhost.com/2008/01/07/how-ruby-on-rails-could-be-much-better/ http://blog.dreamhost.com/2008/01/07/how-ruby-on-rails-could...

alrs 16y ago

I feel very strongly about this. I've done good business coming in and mopping up messes after people that attempt to deploy applications this way. I'll follow up after I'm done with Christmas celebrations, but to think that a random hodgepodge of flavor-of-the-week deploy scripts slapped together by a webdev and scraped from github are somehow better or more maintainable than the collaborative output of some of the world's smartest and most committed developers is flatly-ridiculous. Follow http://planet.debian.org http://planet.debian.org for a week and tell me these people don't know what they're doing.

samdk 16y ago
RVM is hardly a 'random hodgepodge of flavor-of-the-week deploy scripts'. RVM is widely used throughout the Ruby community and for good reason. I'm really not interested in getting into some back-and-forth flamewar about this. (There's been plenty enough of that on the Debian mailing lists and elsewhere already.) I trust that the people maintaining Debian are very smart and do, in general, know what they're doing. But I don't trust that the people maintaining Debian know how to deploy Ruby/Rails better than the people in the Ruby/Rails community.
- zppx 16y ago
  I can see the value of RVM for developers, running the same code against various gemsets and versions of Ruby, I used it this way, but not for deployment, why not simply compile everything necessary by hand, install the necessary gems, say ruby 1.9.2 with rails 3.0.3 and some other gems, and them use the result to chroot personalized deploys (or containerize them) instead of installing various versions of ruby with one shell script? EDIT: Well, since you cannot answer in this thread feel free to answer in my first comment in this thread above if you wish. EDIT2: I found this article about the matter, I found it to be good, I agree with him in the large picture: http://rcrowley.org/articles/dependencies.html http://rcrowley.org/articles/dependencies.html
  - samdk 16y ago
    I'm not really sure I understand your question. RVM is a tool that can do all of that for me, and it's used and vetted by a large community. I don't know why I wouldn't use RVM. RVM automates the compilation step. I'm not sure why I'd want to do that by hand instead. Gem installation is done on a per-app basis using bundler[0] or RVM's gemsets, so the gems for each application are kept separate anyway. Running different applications on different versions of Ruby at once is also easy with project-level rvmrc files. And if for whatever reason you want different RVM installs for different users that's easy too: RVM only installs for a single user by default. Now, granted, I don't do anything like run a shared hosting service, and there may be cases where RVM lacks the flexibility to do what's required, but I've never run into them. [0] http://rubygems.org/gems/bundler http://rubygems.org/gems/bundler