Since we're not calling this lambda from inside a method, the `return`
causes a LocalJumpError on 1.8.x. It appears this functionality works
fine on 1.9.x but we'd like to support both. The correct behavior
appears to use `next`.
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.
I don't use `activated` here because I'd really like to optimize
performance as much as possible, and loading files from disk is
generally slow. So instead of using `activated` I load the file at the
last possible moment which is when the exact class is being requested.
I don't think many people will do this outside of the core, and I'm not
too concerned.
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.
Mitchell Hashimoto
Alvaro Videla
Paul Morton
Matt Robenolt
mxtthias
Jens Braeuer
Marco Monteiro
Mitchell Hashimoto
Marcus Cobden
Zsolt Takács
Matt Callaway
Justin Lynn