find_types works fine until you have a module which has the same name but different case. For example, the VagrantVmware package is HashiCorp::VagrantVMwareDesktop. All the protos are at Hashicorp::Vagrant::… So, you end up with this fun
Object.constants.select { |n| n.to_s.downcase == "hashicorp" }
=> [:HashiCorp, :Hashicorp]
So, when trying to walk down the modules to find the right type to unany to, Vagrant sometimes takes the wrong path (eg. Down the HashiCorp module instead of the Hashicorp module).
This change will keep a list of the parent modules when walking down the module list. This way if a dead end is reached then Vagrant can go a level back and keep searching for the correct class.
Turns out I misinterpreted the behavior of a ruby method with a default
being passed nil so I assumed :parallel was effectively defaulting to
true when it is the opposite.
This removes the need for the validation workaround for Docker, because
box_updated is once again available in that context.
We don't technically need the SyncedFolder priorities back on the Ruby
side, but wiring them through for symmetry.
Depends on https://github.com/hashicorp/vagrant-plugin-sdk/pull/183
The code running in the help subcommand relies on Command plugins being
returned from the manager with their options hash. Stubbing in a blank
hash prevents the command from crashing
What we really need is for CommandOptions to be modeled and passed
through from Go to Ruby so :primary subcommands can be displayed, but
that can be a follow-on task from this quick fix.
Two fixes:
1. Allow us to make it through Vagrant::Environment initialization when
there's no project yet, fixing box add and init commands.
2. Don't prune UNKNOWN targets from state... as VBox looks like it
leaves things in that state when it runs suspend.
By pruning machines that are in "unknown" status after each operation,
the Go code path exposed the fact that the Docker provider was not
updating the machine index during an "up" - leaving the state as
"unknown".
This is basically a bug within the Docker provider, so I think it's okay
to update the plugin code to correct this rather than working around the
issue in Go.
All we need to do is call `machine.state` instead of reaching through to
`machine.provider.state` while waiting for the container to be started.
That causes the extra logic for updating the machine index in
`machine.state` to fire.
