On Fri, 06 Apr 2012 12:33:40 -0700, Ryan Lane <rlane32(a)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
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]