Previously, all procs were assumed to just be the current version. This
is certainly not going to be true always so now the version number of
the configuration must be explicit if you're assigning a proc to the
configuration loader.
This means that the Config::Loader now only knows how to load
configuration for versions used to initialize the class. This lets
things like the tests be completely isolated from what the actual
configuration is for Vagrant. This will be immensely useful to verify
that the loader functionality works for non-trivial bits (like
upgrading) without depending on Vagrant's upgrading functionality.
There was an issue before where the stdin buffer would always have space
so it would always yield that block and Ruby would spin at 100%. Now we
require all callers to say what they want to listen for. This drops
CPU down to almost nothing.
See GH-832
Vagrant is only guaranteeing that the plugin definition superclass (the
Vagrant.plugin("1") part) is backwards compatible. Anything else, such
as Vagrant::Command::Base and so on, will likely change in future
versions. Beacuse of this, plugins should only immediately expose their
definition.
In order to support loading the other classes, plugins should defer
loading to the "activation" phase of a plugin. This can be done using
the `activated` block:
class MyPlugin < Vagrant.plugin("1")
name "my plugin"
activated do
require "myplugin/my_command"
end
command("foo") { MyCommand }
end
Plugin activation is done at two specific times:
* Right when a Vagrant::Environment is created and the global plugins
(such as from ~.vagrantrc) are loaded.
* Right before loading configuration, but after the Vagrantfiles have
been evaluated. This allows plugins to be defined within these files
as well.
Vagrant.configure is now how configuration is done in Vagrantfiles
(previously it was Vagrant::Config.run). This function takes a single
argument which is the version of configuration to use.
Various internals were updated for this new versioned configuration.
Note that multiple versions of configuration aren't yet used so aren't
fully supported by Vagrant, but the foundation is being set here.
Easy commands are well... easy! They don't offer the full power of
creating a completely custom command class, but they let you do the
basics (what almost everyone needs) with minimal fuss. Example:
class MyPlugin < Vagrant.plugin("1")
name "my-plugin"
easy_command "foo" do |action|
puts "HELLO!"
end
end
NOTE: The "action" stuff isn't done yet, but will be soon!
Mitchell Hashimoto
Ryan LeCompte
Sean Wolfe
Mitchell Hashimoto
Christian Rigdon
Bob Van Zant