If the local data directory is unavailable, there will be no local
file to use within the plugin manager. Check for local file before
returning result, otherwise just return an empty hash.
Allow Vagrantfile#machine_config to load properly when the requested
provider may not be currently available. Update the Environment to
utilize this when searching for plugin information to properly allow
box provided Vagrantfiles to define required plugins.
Since plugin installation happens when the environment is first
initialized, attempt to determine the provider in use and load
any box provided Vagrantfiles to include any plugin configuration
they may include.
This commit introduces some basic functionality for typed triggers:
- command
- action
Command triggers are triggers that will run before or after a given
sub-command.
Action triggers are for running triggers before or after internal
actions for Vagrant. This could be before or after a provision step,
before or after synced folders, or networking, etc.
Reloading the Vagrantfile causes issue with multiple evaluations
where users expect single evaluation. Instead of allowing local
plugin installation to happen prior to command execution, force
halt after installation and the command to be re-run. This will
prevent multiple loads of the Vagrantfile within a single run.
Force the vagrantfile and configuration loader to be rebuilt after
plugins have been loaded to properly allow newly introduced plugin
configurations to be properly supported within the Vagrantfile.
When a guest is created, the box metadata information is stored in the
machine data directory. This allows modifications to happen to the
Vagrantfile definition of the box in use (box name change, box version
change, etc) while still allowing the Machine instance of an active
guest successfully load the box currently backing it.
This allows custom paths that include special characters like `~`
to be properly expanded instead of resulting in joined root path
with special characters included.
This causes issues since the child environment almost certainly doesn't
share data with the parent. In a larger scope, we should find a way to
encode the data path somehow on `vagrant up`.
Deleting the lock file can fail when another process is currently trying to acquire it (-> race condition).
It is safe to ignore this error since the other process will eventually acquire the lock and again try to delete the lock file.
