Ruby is awful to install for production.
Can someone direct me to the common complaints, or outline the common complaints here?
https://gist.github.com/bradland/6861980
That's 9 lines of shell if you exclude comments, and includes the MD5 check. I've updated these commands a few times as Ruby has advanced, but most of the changes come with my distro updates. For example, the Debian 7 release required an update to most of the libs that Ruby depends on. Otherwise, it's been relatively trouble free.
1: It's not really a build script. It's a listing of the shell commands you'd need to install Ruby manually. I extracted them from my build scripts.
Here's my take on using rbenv to have the same kind of environment on your laptop and the server - damn fast : http://www.lambdacurry.com/damn-fast-production-ready-ruby-s...
Why are you forced to use RVM on the server? A great number of the issues people face when trying to deploy Rails apps are environment based. Tools like rbenv and RVM are environment managers. They make all kinds of changes to things like PATH, GEM_HOME, etc.
In a production server environment, you want consistency and simplicity. Yes, you can use tools like rbenv or RVM, you but add layers of environment management on top of the base server environment. When you use these tools to manage Ruby on your server, any process or daemon that needs Ruby will first have to ensure that these tools are loaded and invoked properly. It's a layer of indirection that I feel a strong incentive to avoid.
Don't get me wrong. I'm not saying they're not good tools. Quite the opposite. I'm a huge fan of RVM, rbenv, and chruby. I have a deep appreciation of their contribution to the Ruby ecosystem, but I'm one guy. I have a reasonable understanding of Linux system administration, but the more layers of complexity I add, the deeper the water gets. At some point, I'm in over my head.
There are two really great options for installing Ruby on your production servers:
Note: Most Linux distributions give /usr/local/bin priority in PATH by default, which is why I use it instead of /opt. Using /usr/local/bin means you don't need to modify PATH.
1) Use ruby-build [1]. This is the plugin that rbenv uses to install Ruby, and you can use it without rbenv. Once it is installed, this simple invocation will get you a working Ruby install:
ruby-build '2.0.0-p247' '/usr/local'
2) Install from source. In the example above, ruby-build really isn't doing all that much. You still have to have the basic deps (build-essential, zlip, ssl, readline) in place in order to build Ruby, and you have to remain aware of any caveats introduced by new OS or Ruby releases.
I use option 2.
A great way to keep up with what's required to install Ruby on your system is to look at what tools like rbenv and RVM are doing under the hood. These tools act as collectors for the little hacks and workarounds (e.g., ref URL 2 below) that are occasionally required to install Ruby. If you're running a mainstream distro on a recent release, you really shouldn't need much in the way of hacks/workarounds these days. OS X is where a lot of the trouble lies.
1: https://github.com/sstephenson/ruby-build
2: https://github.com/sstephenson/ruby-build/blob/master/bin/ru...
EDIT: Above I said, "[ruby-build] isn't doing all that much", which isn't entirely fair. Ruby-build does do some really nice things like check MD5 hashes. It also checks for common caveats, which I kind of played off. I do the work of looking out for these things, but I'd certainly understand why someone wouldn't want the hassle, and ruby-build does a fantastic job of keeping up with these hassles and automating them away. In short, I want to be crystal clear that I am super appreciative of the work that the rbenv and RVM authors do. They are a tremendous asset to the community.
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
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.
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.
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.
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.
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
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.
I don't have a problem with Ruby, I have a problem with its clusterfuck of programs that reinvent the package management wheel and assume that you're going to send your work over to magicland where all of the Ops wizards will make it into a working product.
The reason it's that way is because most of these people develop on Macs then hand off to someone to deploy on Linux. They don't know anything but web dev, and with PaaS like Heroku, they're never likely to. My warning, though: if the reason you're on a PaaS is because you have no idea of how to deploy, you're going to be paying an ignorance tax. Make Ruby easier to deploy, and PaaS will end up cheaper.
edit: I have no problem with rvm (or virtualenv) as a container to run different versions of a language and dependencies on the same server. To use those tools to run a single system version for a single application would be silly, but since the tools are completely broken for doing that anyway, it's simply impossible to do and to retain dark, lush hair at the same time.