17 Commits

Author SHA1 Message Date
hashicorp-copywrite[bot]
36a312ee26
add missing license headers and update copyright file headers to BUS-1.1 2023-08-10 21:53:25 +01:00
Seth Vargo
d2874064f4 Use .key? instead of .has_key? 2015-01-05 18:29:01 -05:00
Mitchell Hashimoto
af2690635e Unknown keys return a DummyConfig rather than OpenStruct 2013-02-28 00:16:43 -08:00
Mitchell Hashimoto
d15acde8c0 Capture missing key calls in V1 configs and record them as warnings 2013-02-28 00:06:49 -08:00
Mitchell Hashimoto
e0c8fadae4 I can remove the validate! method from the v1 root 2013-01-18 12:18:30 -08:00
Mitchell Hashimoto
0ca783e8d1 V1 config loader loads upgradable config if not V1
This is to prepare for the upcoming V2 configuration. When we're in V2,
we only want to load _upgradable_ configuration keys.
2012-11-03 21:54:32 -07:00
Mitchell Hashimoto
c803b0508a Much cleaner plugin part querying syntax.
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.
2012-11-03 21:25:28 -07:00
Mitchell Hashimoto
6df6f6764f Remove plugin activation. It really isn't necessary.
It was only used in a couple places and it isn't necessary since you can
do the loading within the actual blocks themselves.
2012-11-03 20:29:34 -07:00
Mitchell Hashimoto
798704c6d2 Move the loader into the Config::V1 namespace. 2012-06-26 15:06:03 -07:00
Mitchell Hashimoto
41bc8e7454 Move Config::V1::Base to Vagrant::Plugin::V1::Config 2012-06-24 17:06:11 -07:00
Mitchell Hashimoto
9bc1ea5f04 Use config finalize to move some version-specific logic to the version
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.
2012-06-23 12:48:53 -07:00
Mitchell Hashimoto
95e554314e Foundation for supporting multiple version types
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.
2012-05-20 17:47:24 -07:00
Mitchell Hashimoto
a62e859231 Get rid of the UNSET_VALUE stuff, save it for v2 2012-04-18 17:09:25 -07:00
Mitchell Hashimoto
b38fb5e974 Loader uses the new configuration classes 2012-04-18 17:03:34 -07:00
Mitchell Hashimoto
98d6bf958e Move core config into a plugin 2012-04-17 22:12:27 -07:00
Mitchell Hashimoto
c0ee3b06ff Config merging 2012-04-17 10:22:24 -07:00
Mitchell Hashimoto
92ee042fc2 V1 config loading using plugins as a source for config keys 2012-04-16 22:26:38 -07:00