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.
This command is used in `go generate` but hadn't been pulled into the
nix dependencies yet. Previously I was installing the binary via `go
get` but this is cleaner and more nix-y.
Also includes a `nix flake update` for good measure.
Keeping things pinned to the last released version should hopefully help
minimize comment churn (as each generated run outputs the version in the
comments).
The grpc-tools gem is just a bundle of prebuilt binaries with a thin
layer of wiring to invoke the correct binary given the calling system.
On Nix, prebuilt binaries don't work because they can't find their
dynamically linked libraries in the "normal" places you'd expect on a
Linux machine. Nix has tooling (`autoPatchelf`) which can fixup a given
binary and wire it correctly to the Nix store. We need to have Nix fetch
and build `grpc-tools` so we can invoke this tooling rather than just
letting `bundle install` get the gem.
