Add bundler before/after eval hooks for plugins

[ccutrer]

What was the end-user or developer problem that led to this PR?

My plugin would have a much cleaner implementation if it could hook both before and after the Gemfile is evaluated (the former to easily add additional DSL methods, the latter to do verification that the new methods were properly used).

What is your fix for the problem, implemented in this PR?

Add the hooks and call them from Definition.build (not Dsl#evaluate or Dsl#eval_gemfile, so as not to interfere with the plugin-parsing pass of the Gemfile).

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[binford2k]

This hook would GREATLY help our situation. In the Puppet ecosystem, modules are tested via a Gemfile that declares all the ruby code required to run the tests. One of the requirements is puppet which may now be provided by:

• a gem named openvox
• a gem named puppet from ruby gems
• a gem named puppet from a private authenticated gem server

Each gem is very nearly equivalent and the real difference comes from transitive dependencies. But in order to test that a module works on all three implementations, we need to allow the site operator to select which implementation to install and use.

It's infeasible to require every author of every module to add boilerplate code to their Gemfile to select a gem to install.

My https://github.com/overlookinfra/bundler-alias plugin now handles all but one case, and that would be enabled by this contribution.

[Edouard-chin]

Having a hook to extend the DSL is also something I'm looking for. I was about to propose a patch but saw this PR.

For the maintainers that will review this PR, having an official way to extend the dsl would allow Rubist to more easily build tooling, and implement Bundler features that could make it upstream if they are popular in the community.
Right now, it's possible but your Gemfile would look like this:

plugin 'foo'

if Plugin.installed?(:foo)
  Plugin.send(:load_plugins, :foo)

  my_cool_new_dsl_method
end

[Edouard-chin]

I think the hook should be in the dsl file. If the intent is to let plugin extend the dsl, then we should pass the dsl class to the hook.
So the plugin would be able to do something like:

Bundler::Plugin::API.hook(Plugin::Events) do |dsl|
  dsl.define_method(:overrides!) {}
end

We'd also need to passthrough method_missing

rubygems/bundler/lib/bundler/plugin/dsl.rb

Line 35 in 43f15a1

def method_missing(name, *args)

in the DSL plugin, otherwise users won't be able to use ours custom dsl methods.
If a user accidentaly call a methods that doesn't exist (either in the vanilla Bundler dsl or our custom plugins) it will be caught afterwards when Bundler evaluates the DSL from the DSL class

rubygems/bundler/lib/bundler/dsl.rb

Lines 236 to 239 in 43f15a1

	def method_missing(name, *args)
	raise GemfileError, "Undefined local variable or method `#{name}' for Gemfile"
	end