On Fri, 06 Apr 2012 12:33:40 -0700, Ryan Lane rlane32@gmail.com wrote:
We've already gone down the Ruby road once. I think a lot of the
people involved with that would say it was a bad call, especially ops.
Ruby at scale can certainly be a lulz engine, especially for those on the sidelines. This project doesn't seem to place any software demands on the production cluster, or even necessarily require anything from ops though.
I had mentioned in IRC that I don't have any major ops objections as long as whatever gems are required are installable via apt in some way, rather than using gems.
Ryan, I only ran into it recently. But look over bundler: http://gembundler.com/rationale.html If another situation where something needs gems without existing apt packages comes up it may be a helpful thing to have in your toolkit of solutions.
Two useful things that bundler seems to provide: - In deployment it can install gems in a place local to the application. So instead of using `gem` or apt to globally install the gems needed they'll be installed locally in a way that won't conflict with other applications. - Bundler uses a Gemfile.lock setup; When you initially install and updated gems on development it tracks the installed versions of every single dependency installed (even indirect ones you didn't depend on directly). And when you develop you check this file into version control with the rest of your source code. Using this setup bundler ensures that every gem you install using bundler (especially under deployment) is installed using the exact same version of the gem that you used during development.; So if you're using apt and a central apt sources server to ensure that all servers have the same package versions installed, bundler should help you attain that same goal with gems that don't have apt packages.
- Ryan