I read this from time to time and I don't get it. This is literally what I do on Ubuntu LTS:
sudo apt-get install build-essential openssl-dev zlib1g-dev
wget http://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p0.tar.gz
tar xvfz ruby-2.0.0-p0
cd ruby-2.0.0-p0
./configure && make && sudo make install
This is not hard, and it's never caused me any kind of trouble.
A few months ago, I ran into psych/yaml problems doing just the above because I didn't have the right yaml libraries installed.
Also, if you did that and also did something like "apt-get install chef" or something that installs the system ruby, you will have two copies of ruby installed and need to make sure your $path is correct.
I just started learning Chef, and all I can say, vis-a-vis Ruby, is "F%!#, what a nightmare". Now, to be fair, the version of Ubuntu I was on was a bit out of date, and I'm not a "Ruby guy" so I knew bugger all about rbenv, RVM and the like going in. But that was downright painful.
I don't know what life is like for Rails devs, but just getting Chef up and running is painful enough that it killed any latent interest I might have had in ever diving into Ruby.
What was painful about it? Chef provides Debian packages. I added their repository, then apt-get install chef, and it was done. I use chef-solo, and every time it just worked. What sorts of problems did you experience?
I was following one of their tutorials and it had you doing things like using rbenv and bundler, and none of that crap worked right. I don't remember the specific error messages, but it was all crap like "Can't load Gem <such and such>" or "can't load required file <blah>", etc, etc.
In that case, part of the problem was documentation (as far as I can tell in retrospect, I never really needed anything other than the Ruby 1.8.7 I already had installed), but just being exposed to rbenv and the mess of that world left a bad taste in my mouth.
Of course, it's not just Ruby. I have no use for the similar tools for any environment, that purport to let you keep multiple versions installed simultaneously. Whether it's for Python, Groovy, Ruby, whatever. I've come to the conclusion that it's just plain A Bad Idea to do that sort of thing.
Maybe that tutorial was old. Use their Debian packages. It bundles a private Ruby that is only used for running Chef. It always works and never breaks.
Interesting... I guess I didn't find any packages that bundle private Ruby, or if it does it does it behind the scenes and I just don't know it. But what I'm fighting with now, is install some Gems that one of the tutorials has you install... when I run "bundle install", one of the Gems flakes out because it requires Ruby > 1.9.1, and doing a "apt-get install rubygems" earlier apparently made Ruby 1.8.7 the default on this box again.
Ran "update-alternatives" and set Ruby back to 1.9.3 and now when I try to install the Gems, I get failures like:
"in `require': cannot load such file -- mkmf (LoadError)"
I think I'm making progress, but man, this is frustrating.
To be fair though, the basic Chef install is done and working, and I can run "knife client list" and see my clients. It's just that I'm trying to get through this EC2 tutorial and it has you installing this specific list of Gems, and that's where the problems are now. sigh
Yes I can see why installing Ruby is frustrating wit those kinds of errors. The thing is, Debian split Ruby into multiple packages, but made a lot of them not installed by default, which causes a lot of headache for users. The mkmf thing is supposed to be a standard part of Ruby, and most developers assume it is always available, but I Debian put it in `ruby-dev` I think, so you get that error if you don't `apt-get install ruby-dev`.
If you're not a Rubyist and just wants to use Chef, Chef's own Debian packages work great. You can ignore RubyGems and update-alternatives and other stuff, Chef's Debian packages provide everything you need.
I think that Chef should go through the tutorials and clean up the old things.
Yes, you do have to know your deps, but the deps don't change very frequently. Common Ruby build tools will tell you what the deps are for your operating system, even if you're not going to use them in production (I don't).
As far as system Rubies go, I try to keep things simple. I use Debian for my systems, so I know that `/usr/local/bin` will always be first in my path, so that's where I install.
This falls far short of "awful" in my opinion. There are many pieces of software that are far more difficult to compile from source.
