bundlerext / 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)

bundler_ext

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

API

• BundlerExt#system_require is analogous to Bundler#require and will auto-require the gems loaded in the Gemfile wherever they are installed / can be found.

• BundlerExt#system_setup is analogous to Bundler#setup and will setup the Ruby LOAD_PATH to only incorporate the gemfile dependency include paths wherever they are installed.

• If either case if the BEXT_ACTIVATE_VERSIONS env var is set true, the specific versions of the gem installed via yum/apt/other will be detected and activated.

• Specify the BEXT_GROUPS env var to insert additional groups to be loaded (separated by whitespace, eg BEXT_GROUPS='group1 group2 ...')

• Specify BEXT_NOSTRICT to disable fail-on-error, otherwise BundlerExt will raise a critical error if a dependency fails to load. If set true, BundlerExt will simply print the msg to stdout and continue on.

Show Me The Code!

Assuming gemfile_in is defined as

gemfile_in = File.expand_path('../../Gemfile.in', __FILE__)

To load & require ALL Gemfile groups, use the following statement:

BundlerExt.system_require(gemfile_in, :all)

To load only the default one, use:

BundlerExt.system_require(gemfile_in, :default)

BundlerExt#system_require function takes a list of parameters corresponding to all the environments the invoker intends to use.

To require the default group and the group specified by the Rails environment, use:

BundlerExt.system_require(gemfile_in, :default, Rails.env)

To setup the LOAD_PATH to only reference the default Gemfile deps:

BundlerExt.system_setup(gemfile_in, :default)

And so on....

Other Considerations

You may want to wrap your call in some kind of check, to allow non-platform users to still use bundler if they want to.

One way to accomplish this would be to simply change the name of the Gemfile for native package system scenarios, eg

mv Gemfile Gemfile.in

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

Some rubygems require HOME environment variable to be set, threfore not running daemonized. For this purposes there is BEXT_HOME variable which can be used to set HOME environment variable before any rubygem gets loaded. The variable is not exported for subprocesses.

License

bundler_ext is licensed under the MIT Licence.

• http://www.opensource.org/licenses/MIT

bundler_ext's Issues

Move bundler_ext from incubator

I think it is the time to move it out since it is proven and there are projects out there heavily making use of it :-D

Good work guys.

New release request

Any chance we could get a new release of the bundler_ext gem, ideally incorporating the docs / tests PR, but at least w/ the new BundlerExt#system_setup stuff

We've leveraged this for our needs and are looking to cut a new release of the RPM. Thanks

Please drop shebang from Rakefile

There is no point in having shebang in Rakefile, since the Rakefile does not do anything by default. Please remove it. Thanks.

Can the aeolus namespace be dropped?

I consider it a bit unfortunate, that the bundler_ext is in Aeolus namespace. It should be either renamed to something like aeolus-bundler_ext to reflect its dependency to Aeolus, or better, the namespace should be dropped, since it seem that there might benefit other project then Aeolus from this gem.

Make bundler_ext to determine requires properly

Bundler can determine require statements properly somehow. Kind a magic for me, but until this issue is resolved, we need to add :require to those gems. Would be nice to have this. Low priority.

Add travis configuration (and probably Gemfile)

Test suite error testing with Bundler 1.13.6

After update of Bundler in Fedora to 1.13.6 version, bundler_ext test suite started to fail in Koschei [1] with following message:

  1) BundlerExt::Runtime#bundler returns handle to bundler runtime
     Failure/Error: bundler.root.to_s.should == File.expand_path('spec/fixtures')
     NoMethodError:
       undefined method `root' for #<Bundler::Runtime:0x581f4868>
     # ./spec/bundler_ext/runtime_spec.rb:34:in `block (3 levels) in <module:BundlerExt>'

[1] https://apps.fedoraproject.org/koschei/package/rubygem-bundler_ext?collection=f26

Support for custom path specification

In Gemfile people can specify :path. I think it would be useful to support this as well if specific instance of a gem is preferred over the system one.

Maintained?

Is the gem actively maintained?

Would you like some help? I'd be willing to co-maintain to merge PRs (especially #18) , get tests running here and publish a new release if necessary.

Test suite seems to be underspecified

Not sure what is the intention of the test suite, but since spec/fixtures/Gemfile.in specifies plenty of gems, I would expect that all of them must be available on the system to pass the test suite. But in reality, it is enough to install rubygem-deltacloud-client. Shouldn't be the test suite more precise?