Isn't installing Ruby from apt-get ok, since RVM just manages that as the 'system' ruby alongside all the other Ruby's RVM can install and manage? Not sure about gems or other packages though.
What the blogger probably meant was "don't use Ubuntu's Ruby" for any serious development (since it's out of date and crippled).
As far as it goes, you can certainly install Ruby with apt-get or aptitude, but I think the response then would be "Why bother?", assuming you're not going to use it anyhow.
One other thing: rvm doesn't really "manage" the system Ruby. You can issue the command 'rvm system', but what that really does is remove the rvm directories from your $PATH. rvm itself never touches the Ruby interpreter or libraries installed via APT.
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.
> "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.
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 for a week and tell me these people don't know what they're doing.
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.
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.
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.
It only sounds ridiculous because you don't know the full story. We've already had a lengthy discussion on debian's packaging before, including rubygems: http://news.ycombinator.com/item?id=1734936
technomancy summed it up: "The rubygems devs have asked nicely to get Debian to fix these issues, and have been turned down flatly... Debian is the only distributor who breaks rubygems when packaging it."
I've tried developing Ruby on Ubuntu using the ruby packages, and it's been a huge pain every time. They've also handled ruby1.9 in a maddening way--with separate 1.9 binaries for everything. And rubygems is very broken (though it's probably their position that ruby libraries should be installed through apt also). I accept that their decisions were made with an eye towards users and they may well be the right ones for them. For developers, though, it's awful.
Fortunately RVM gives the best of all worlds: it's consistent between distros and operating systems (I develop on OS X and deploy onto Ubuntu and Cent OS--everything works the same in both places). Switching between ruby versions is as simple as `rvm 1.9.2`. You can easily specify a ruby version to use for different scripts, ensuring that whatever is best for a particular program can be used. And most importantly, it just works.
RVM is in my mind the biggest improvement to ruby development in the last couple of years. I'm sorry if the Debian packagers feel its encroaching on their territory, but it serves our needs as they do not.
I'm not sure where your skepticism is coming from, but I can assure you that I would have saved countless hours had I begun with a more current version of Rubygems and Ruby.
Despite much effort from some Debian maintainers, packaged Ruby remains hopelessly broken on those systems. Some of the breakage is deliberate because Debian's policies.
I think the same way, I would expect something like the following from a book author: "Since we're going to install Rails 3 which is newer than the version packaged/available in Ubuntu 10.10, we will do a separate install which is not compatible with the package manager, etc."
This is a good start for setting up rails on your development box, but when it comes to deploying it to a clean server, just following these instructions will give you a headache fast.
Edit: After recursively chowning the .gem folder in my home directory to my user it worked.
I spent a good amount of time trying to get this to work a few days ago, but had issues with rvm. Thought this post might help, but in a fresh 10.10 install if rvm is used when trying gem install rails I get the following
: While executing gem ... (Errno::EACCES)
Permission denied
It shouldn't be denied though since it's in the home directory. The only way I could get an up to date ruby and rails installed was by removing rvm (rvm implode) and manually installing 1.9.2 and then following the update-alternatives instructions located here: http://ubuntuforums.org/showthread.php?p=10274200#post102742...
Is anybody else successfully accomplishing it the way this blog suggests? The internet is relatively sparse with up to date instructions for installing rails without problems on Ubuntu, it makes me miss the rolling release model of arch where everything just worked instantly.
Did you install rvm locally, or system wide? I have never had a real problem installing rails with rvm on 10.10, I just had to apt-get the required libs for ruby, and then everything else worked fine (with a normal rvm install).
I would try rvmsudo gem install rails, who knows...
Also remember, when you run the rvm install script or any of the following rvm commands, dont sudo it for a normal installation.
I installed it locally, but for some reason the .gem folder was root user and not my local user so it would not allow me to run gem install rails unless I used sudo. To fix this I had to chown the .gem folder to my user and then everything worked as it should. I just found it strange that I was the only one that seemed to have this issue since it looks like it should happen to everyone who follows the steps.
It's surprising that with all that talk about how bad packaged ruby is, not many seem to be pushing for automation to fix this. CPAN situation is very similar to gems (apart from the speed of changes in the interpreters). Some perl modules are missing, some outdated, but `dh-make-perl --cpan Module::You::Want` brings you all you need almost every single time. There seems to be an old dh-make-ruby (dead ~2006), dh-make-gem seems to be in the works (early 0.3.0 version available).
Even upstream doesn't seem to be interested that much. On the download page, there's:
For example, on Debian or Ubuntu apt-get provides an easy and elegant solution:
% sudo apt-get install ruby1.9.1-full
It definitely is confusing / silly to the outside observer... There's rvm - how hard is it to automate package building reusing it's elements? If it's not - why isn't it done? If it is - why all the packages hate, instead of pressuring upstream to improve the situation?
Actually, this is one of the long lasting issues with RoR: most people want to try it on a recent version, but Linux distros try to package stable releases instead. You shouldn't blame the distros for not having the absolute bleeding edge version.
If really need the absolute latest version of Rails go on, have a separate install compiled from source, but there's no need to be rude with the packagers. I'm trying to learn Rails 3 and I found that JRuby works really fine with Rails 3, and using Warbler gives me nices WAR files to deploy on Tomcat, and I don't mess my default Ruby install.
Ruby 1.9.2 and Rails 3.0.3 are now considered stable by what appears to be everyone but the packagers.
apt installs Ruby using a non-standard configuration too, when you do `apt-get install ruby1.8`, the executable is `ruby1.8`. Nobody in their right minds these days would install it with the `1.8` suffix.
Ruby version management is best taken care of with RVM, as that's better built for it than a general package manager such as apt.
As a compliment to my sibling's Rails comment, they're still shipping Ruby 1.8 as well, which hasn't been the main version of Ruby since January of 2009.
Additionally, apt also packages "ruby-1.9.1" which actually installs Ruby 1.9.2. More evidence that apt is fundamentally broken when it comes to Ruby package management.
No. Apt works and does not enforce what versions you use and what you call them. Debian policies are another thing. But I wouldn't call stuff fundamentally broken that quickly. Once you actually get into packaging - versioning and dependencies stop being that simple thing really. Especially if you want more than one person to use your package in a stable environment.
Also "In the name of this package, `1.9.1' indicates the Ruby library compatibility version. This package currently provides the `1.9.2' branch of Ruby, which is compatible with the `1.9.1' branch." (http://packages.debian.org/sid/ruby1.9.1)
Absolutely agree. Whenever you google for installing ruby on Ubuntu you get the package version. Also Linode's guides use the packages. RVM offers a nearly effortless solution to manage your rubies - and more importantly manage gemsets which is an awesome feature.
Honestly, the setup isn't that complicated that it should take anybody who's following any kind of instructions any time at all. Even compiling from source is pretty straight forward... although there's a couple of "mystery packages" like libreadline that you have to have installed to get things like irb working.
That's why there's guides out there to show you how to do this. My final run through of just copy-pasting the examples in the post took all of 20 minutes and most of that time was spent waiting for Ruby to compile.
Basing your choice of the framework and even the language for your project on some error during what seems to be your first installation ever of that specific stack is really not a good idea. Installation and deployment are well solved problems with both technologies, and there are so many other factors to consider depending on what you're building.
I just did this setup a few days ago, only problem is rvm did not work with root, still uses default ruby, however i suspect i need to configure the PATH
I really wish the RoR book I was reading had told me that before I spent multiple hours trying to properly setup Rails.