Boxes are provider-specific, and we don't know the provider until
Environment#machine is called, so we need to build up the machine
configuration during this time.
This will eventually replace the Environment#vms method. Because of the
introduction of providers, the environment doesn't know what the backing
of the machines will be (and they're _machines_ now, not _vms_).
Instead, users of Environment will now call `#machine` on the
environment to retrieve a machine with the given backing provider as it
needs it.
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 can be removed since in the future all actions will come from the
providers or something. There are still issues with box actions but
we'll get back to that later...
This starts the transition of replacing VM with Machine. Machine still
isn't ready to fully replace VM but by moving it now, I'm able to find
the spots that need to be fixed. At this point `vagrant status` works
with the new provider interface.
This involved defaulting all box searching at the moment to VirtualBox.
Additionally, box upgrading is not yet handled. This needs to be done at
some point.
This moves out the concept of a "default VM" from the Environment class
and makes it the responsibility of the V1 configuration that at least
one VM is defined on it. This lets the configuration ultimately decide
what a "default" implementation is.
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.
I wanted to define my dotfile as: `config.vagrant.dotfile_name =
"~/.vagrant-projectname"` and noticed that the full path wasn't
expanded as expected.
This patch allows the vagrant file to be placed anywhere on the
filesystem.
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.
This changed plugin loading semantics a tiny bit, since they are
no longer loaded when Vagrant is loaded but instead when the
Vagrant::Environment is initialized. I'll note this in the CHANGELOG.
