Still work left to do on exec and stderr separation but this represents
enough working to let vagrant-spec assertions pass so I think it's worth a
checkpoint!
* `vagrant ssh` has a --no-tty flag colliding with the one defined in
`bin/vagrant` - in fact none of the flags in `bin/vagrant` are
processed in `serve` mode, so remove the code that captures them from
the CommandInfo OptionParser dance
* `vagrant ssh` has a `--plain` flag colliding with the one defined in
`internal/cli/base.go` - this flag was inherited from Waypoint, so we
can just rename it to line up with the (inversely defined) `--color`
flag used in legacy vagrant
Some commands like `vagrant init` and `vagrant box` should be able to
run successfully without a full Project available in VAGRANT_CWD (in
other words, they don't require that a valid Vagrantfile be available.)
Thus far we've been assuming that a Project is available when
dispatching commands, which mean that commands of this nature weren't
working.
Here we make the Basis available to serve as an alternative client to
Vagrant::Environment::Remote such that it can be instantiated and passed
through to commands. This required some changes to Environment::Remote
to make its interactions with the client more defensive, but we manage
to avoid needing to make any changes to the normal legacy codepaths.
Having these objects populate their seeds during `Run` was too late for
those values to show up in command plugins, which would be seeded with
empty args instead.
h/t @chrisroberts for the debugging help and fix suggestion!
If the box does not exist in the db, then a box will be returned
with the name and provider information. All other box information
at that point is unknown.
The type needs a string pointer now. We may end up wanting a string
pointer making convenience method in the SDK at some point, but for now
I punted on that question and just made one for the test.
