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.
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
Easy commands can now easily get arguments from the command line.
Using `arg`, you can get named arguments on the command line, such as
"--foo" or "-f"
With `arg_extra`, you can get any remaining arguments after a "--"
on the command line, which is a common pattern used to grab longer
parameters.
Some new APIs were added to the easy command operations. `info`,
`error`, and `success` are simple ways to output messages to the UI
without resorting to "puts" in Ruby, since the Vagrant UI object is the
idiomatic way to do communication with the world.
Additionally, `argv` was added which gives commands access to the
command-line arguments that are remaining that does not include the
vagrant binary or subcommand.
Also, behavior was changed: Previously, easy commands would run for
every target VM. Now, it is only run once with the primary VM. In the
next commit, I plan on adding a new flag that signifies an easy command
is meant to work with a named VM.
This change makes it so that SSH errors are shown, whereas QUIET hid
those as well. The main change to QUIET was to get rid of warnings,
not errors, so this fixes that.
Before, it only contained the shell executable and "-l" was magically
appended to it. However, every shell doesn't support "-l" and maybe "-l"
isn't even the behavior that users want!
Therefore, the config.ssh.shell command must now contain the full
command to execute.
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.
I created VersionBase which is the abstract base class for any
configuration versions. Configuration versions are responsible for
knowing how to load configuration given a proc (from a
Vagrant.configure block), as well as merging configuration procs. In the
future, it will have to upgrade versions as well. This is not done yet.
The VERSIONS constant was added to Vagrant::Config which is a registry
to keep track of all the available configuration versions. The
VERSIONS_ORDER constant is an array of the ordering of these versions.
The ordering is important so that in the future Vagrant can attempt to
gracefully upgrade the configurations. It is also used to determine the
current configuration version (which is assumed to be the last version
in the order).
The loader was modified to use the current version and the VERSIONS
registry instead of hardcoding V1.
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!
Matt Robenolt
mxtthias
Mitchell Hashimoto
Zsolt Takács
Matt Callaway
Josh Mahowald
Mitchell Hashimoto
Ryan LeCompte
Jorgen H. Fjeld
Sean Wolfe
Lars Fronius