I just want to say that I love Capistrano. Even though I don't use it all the time, I still think it's a really great way of deploying when you aren't in a container-based workflow and you just want a quick way of running remote commands from your local machine.
As for your comment, "Ruby is pathologically difficult to install correctly on modern Linux distributions", I disagree wholeheartedly with this. It may be more difficult to install than a simple `apt-get`, but if you're used to compiling from source and you know what the hard dependencies are, it's really not a huge problem. ruby-install and ruby-build of course make this easier but those tools don't require the use of RVM or rbenv, especially on a machine where you know there will only be one Ruby. However, you're correct in the assumption that Ruby could be a lot easier to install if the language creators would move towards that. That said, I think there are a lot of people who are unfairly blaming you for their own misunderstandings of what these tools do and how they are used. For example, chruby or rbenv is absolutely vital on my dev machine because I work with projects using different versions of Ruby. But it's just bad practice to have a production box running multiple versions of Ruby, in my opinion.
I really feel that the users you've interacted with may have been frustrated by their own misunderstanding of the tools they're using, because it's really not as hard as a lot of people make it out to be...
I compile Ruby from source for all my deployments (Debian based). I only need to apt install a handful of build deps and the build goes off without a hitch every time.
Can someone direct me to the common complaints, or outline the common complaints here?
Your method is sane, the problem is with RVM and rbenv, which everyone uses and depend on hacky implicit shell BS (rbenv less so, but it's still there). Build from source and use the full path to the interpreter is the only sane method IMO.
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.
I think the fundamental problem is that on your laptop you use the system's package manager to manage gems and dependencies, while on the server you suddenly are forced to use RVM.
> ...while on the server you suddenly are forced to use RVM.
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'
Because of the reasons outlined in the note above, this type of Ruby install will "just work", even for utilities that shell out with bare shells like `sh -c 'some command here'`. This is because we installed to paths that work with the bare minimum environment.
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.
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.
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.
Let me reply to myself. Try to automate a Ruby installation on Debian without using a PPA (like the awesome service that Brightbox is providing everyone at http://wiki.brightbox.co.uk/docs:ruby-ng ) or installing a compiler on your production server.
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.
It might be a problem with your OS/distribution if you feel like it is awful to use in production. FreeBSD, for example, provides an excellent ruby version in it's package repository (and can have all of them installed, 1.8, 1.9, 2.0, rubinius, jruby, etc) and it's very easy to manage. This is true, I am sure, for many linux distributions as well, and many other OSes. I don't see how ruby can be blamed here.
As for your comment, "Ruby is pathologically difficult to install correctly on modern Linux distributions", I disagree wholeheartedly with this. It may be more difficult to install than a simple `apt-get`, but if you're used to compiling from source and you know what the hard dependencies are, it's really not a huge problem. ruby-install and ruby-build of course make this easier but those tools don't require the use of RVM or rbenv, especially on a machine where you know there will only be one Ruby. However, you're correct in the assumption that Ruby could be a lot easier to install if the language creators would move towards that. That said, I think there are a lot of people who are unfairly blaming you for their own misunderstandings of what these tools do and how they are used. For example, chruby or rbenv is absolutely vital on my dev machine because I work with projects using different versions of Ruby. But it's just bad practice to have a production box running multiple versions of Ruby, in my opinion.
I really feel that the users you've interacted with may have been frustrated by their own misunderstanding of the tools they're using, because it's really not as hard as a lot of people make it out to be...