Temporary limitation of Vagrant to only allow one active machine with a
provider at a time. That means you cant `up` a machine with both vmware
and virtualbox at the same time. In the future you will be able to but
to avoid various edge cases for now we're disallowing it.
This works by registering a `config` with `:provider => true` with the
same name as your provider. Vagrant will then automatically configure
the provider when `config.vm.provider` is used.
This is done by calling the `upgrade` method on the _old_ configuration
classes. The old configuration classes are given the complete new
configuration and can set whatever settings they need to on it.
These are classes that use NO core classes of Vagrant, and are therefore
safe to load for upgrades. i.e. a V2 core can load a V1 config class
that is deemed upgrade safe without crashing Vagrant.
Before we were manually going over every plugin and getting each piece,
all over the place. Now we have a central manager that will give us all
the pieces we want. There is still some cleanup to do here but this is
much better overall.
This required some modifications to the linux guest implementation. And
the other guests will have to be modified as well. This is because
`channel` is now `communicate`.
The future of subclassing things like configuration bases and so on will
be to use `Vagrant.plugin(version, component)`. For example:
`Vagrant.plugin("1", :provisioner)`.
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.
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!
