This is a trade-off. "Just use the full path to ruby" isn't a terribly convenient solution, because using the full path isn't the "Unix way". Putting your custom Ruby in the path is helpful, but in a server environment where I would assume you're using a lot of automation, that's going to take some tweaking. Users of RVM know this well.<p>I guess I don't really understand what the author is advocating? In "production", we don't run multiple apps requiring different Ruby versions on the same VM. Ruby 1.9 has been around for quite a while now, so there's not a lot of fragmentation. We only run one version of Ruby, but we install it to a location that a "stock" environment supports well. Usually it's prefix=/usr/local. Then we treat VMs as disposable containers. I don't build VMs by hand; I let my build tool do that, so upgrading infrastructure versions usually goes something like this:<p>* Update the build script and test with a local VM<p>* Build a new staging VM and migrate the staging instance there<p>* Once we're confident, do the same to production
For some time I always create user deploy and install nginx through passenger on rbenv (if there is only one app on server) or create separate user per app and run everything using rbenv+unicorn+nging from apt. Works flawlessly. I can't agree more, that reating chef recipe is step forward.