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.
If that goal is constantly changing versions of packages that may or may not have proper security patches applied due to dependency chains, then yes, it meets the goal.
I hate programming language package installers like pip, gems, etc. When Ubuntu ships versions of things, they keep stable versions and backport security fixes. This ensures that you'll have a consistent environment until you upgrade the OS, and that security patches are applied properly for everything in this environment.
If your application depends on gem blah-0.1, and specifies that, then you won't get security patches since gems expects you'll just upgrade to blah-0.9. It fills me with rage.
- Ryan