Prior to this commit, vagrant was not grabbing all of the tokens on
Windows for showing the full drive because the ruby api for it behaves
differenly on windows compared to other platforms. This commit changes
that by ensuring the letter drive is attached to the path when showing
an exception.
This commit adds some additional handling for when Vagrant loads config
files. Instead of showing the basic ruby exception, it prints a more
helpful error message and tries to direct the user to the line number
and file where the exception is occuring.
Prior to this commit, if a user set the env var VAGRANT_HOME to be the
same directory where the project home is, Vagrant would load that file
twice and merge its config. This caused various provisioner and other
provider blocks to unexpectedly run twice. This commit updates the
config loader to look and see if the `:root` and `:home` procs are
equal, and if so, removes the `:home` object so that it isn't loaded and
duplicated. This commit however does not prevent duplicate loading if an
identical Vagrantfile exists in the home and project dir if those
locations are different.
Here we implement a naive solution to #5605 which catches the case that
a provided source contains an object which cannot be inspected, because
an object contained within in has an #inspect string that returns a
string that is incompatible with the encoding in
`Encoding.default_external` or a string which cannot be downcast to
7-bit ascii.
The Ruby VM implementation of "#inspect" implements this checking on
these lines of code: http://git.io/vZYNS. A Ruby level override of
this method does not cause this problem. For example:
```ruby
class Foo
def inspect
"😍".encode("UTF-16LE")
end
```
will not cause the problem, because that's a Ruby implementation and the
VM's checks don't occur.
However, if we have an Object which **does** use the VM implementation
of inspect, that contains an object that has an inspect string which
returns non-ascii, we encounter the bug. For example:
```ruby
class Bar
def inspect
"😍".encode("UTF-16LE")
end
end
class Foo
def initialize
@bar = Bar.new
end
end
Foo.new.inspect
```
Will cause the issue.
The solution this patch provides basically catches the encoding error
and inserts a string which attempts to help the user work out which
object was provided without blowing up. Most likely, this was caused
by a user having a weird encoding coming out of one of the sources
passed in, but without a full repro case, it's not clear whether a patch
should be applied to a different object in the system.
Closes#5605.
If the Vagrantfile has some kind of error, display not only
its path and the exception message, but also the originating
line number and exception class.
Also log the full backtrace when the error is in a provider
block, just as it is done when it's outside a provider block.
The basic process for this is to:
1. Load the configuration using the proper loader for that version. i.e.
if you're loading V1 config, then use the V1 loader.
2. If we just loaded a version that isn't current (imagine we're
currently at V3), then we need to upgrade that config. So we first
ask the V2 loader to upgrade the V1 config to V2, then we ask the V3
loader to upgrade the V2 config to V3. We keep track of warnings and
errors throughout this process.
3. Finally, we have a current config, so we merge it into the in-process
configuration that is being loaded.
This is useful so that it can take a look at the final loaded
configuration object and possibly make some tweaks to the configuration
object. The use case this was built for was so that config V1 can verify
that there is always at least a single VM defined as a sub-VM, the
"default" VM.
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.
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.
Config::Loader will be the new class responsible for loading configuration
and replaces the previous dual-role "Vagrant::Config" played. While this
commit is very early-stage, once this new architecture is flushed out, it
will make loading, using, and extending configuration much easier and cleaner.
Additionally, I believe this will help post Vagrant 1.0 if multi-language
configuration is implemented.
