bundler_ext
===========

Simple library leveraging the Bundler Gemfile DSL to load gems already
on the system and managed by the systems package manager
(like yum/apt).

The purpose of this library is to allow, for instance, yum and rpm to
manage the dependencies for a project, and simply reuse the Gemfile
to get the list of directly required gems for (in initial use case) a
Rails 3.x application. It would be useful in such cases for there to
be a big switch in Bundler that would allow the user to tell it 'You
are allevaiated of the responsibility of resolving dependencies, that
has been taken care of for you. Understandably, since Bundler's
primary goal is exactly to resolve those dependencies, that project
has to date not been interested in supporting such functionality.
However, this is the use case for many linux systems, and this library
is an initial attempt to get the two approaches to not step on each
other.

### Example usage: ###

    Aeolus::Ext::BundlerExt.system_require(File.expand_path('../../Gemfile.in', __FILE__),:default, Rails.env)

You may also want to wrap your call in some kind of check, to allow
non-platform users (ie, mac, or any developer not installing as a
sysadmin) to still use bundler if they want to.  One example would be
to simply change the name of the Gemfile for rpm setups, something
like:

    mv Gemfile Gemfile.in

Then, just look for a Gemfile, otherwise, load deps via
Gemfile.in/BundlerExt.

Note there is a reason for the 2 files names (for now at least) -
Some libraries, like Rspec, Cucumber, and Rails, try to be smart and
load up dependencies via Bundler themselves if they see a Gemfile in
the working directory.  In some cases this can be overriden, but not
all, so for now at least, it is safer to just look for a different
file (and this is easily scripted as well) In the linux deployment
case, this is not the desired behavior, we explicitly want to say
'just use what the package manager has installed'.