After lots of experimentation I have landed on this as my proposal for
how we have our Go binary find its Ruby counterpart: just have it grab
it from the $PATH! @evanphx showed me this neat trick where by borrowing
a couple of helper methods from `exec` and tweaking them we can get
logic that will do a $PATH lookup that excludes "ourself". This allows
us to have both `vagrant` executables on the path... and means that
switching between Gogo-by-default or Legacy-by-default is just a matter
of tweaking $PATH order.
It _also_ means that we don't need any different lookup logic for
"release mode" vs "development mode" which is what I was looking at
before this solution.
In order to continue to facilitate development, I've generated a binstub
for vagrant using `bundle binstubs vagrant --standalone --path
./binstubs`, and I've updated the Nix development setup to prepend this
directory to the $PATH.
NOTE: Non-Nix users will need to modify their $PATH in the same way to
get the same behavior in development.
Found this while running `./vagrant box` with no args to get the help
output. It turns out you can have an empty RunResult but also a nil
error. I took the occasion to unwind the conditional tree a bit which
hopefully makes it a bit easier to read.
In legacy Vagrant, any exception raised that's a subclass of
Vagrant::Errors::VagrantError is considered user-facing and so causes
the error message to be printed to the console and the process to use
exit code 1. Anything outside of that causes the process to use exit
code 255. (See `bin/vagrant` for the code.)
Here we mirror that behavior by treating errors that have a
LocalizedMessage as user-facing and those without as unexpected. This
allows the basic virtualbox component to pass in vagrant-spec!
* `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.
