There are some cases where the error that gets returned from scope.Run
is not a core.CommandError which results in a type mismatch panic. This
fixes that and wraps any generic errors into the proper response struct.
- Defaultable needs to default to true when it's not specified
- We need to allow a non-defaultable provider to be selected if it shows
up in the config
These changes address the following warning showing up on `go get`
operations:
go: module github.com/golang/protobuf is deprecated: Use the
"google.golang.org/protobuf" module instead.
All changes are made using the recommendations in the per-function
deprecation notices from the docs at
https://pkg.go.dev/github.com/golang/protobuf/ptypes
* Populates ComponentOptions into plugin structs
* Maps options for legacy Provider Plugins into PluginOptions
* Demos use of PluginOptions in a stub provider
* Honors plugin priority and defaultable settings
It turns out that synced folder plugins aren't returned in a consistent
order, which was causing all kinds of mayhem.
We can tone down that mayhem by implementing a shim of priority sorting
the plugins. This shim can be removed once we have proper priority
registration in the SDK.
Instead of only targets with empty providers. This helps address a
problem that @soapy1 found in review where machines that failed to come
up would get stuck with the wrong provider.
It looks like I might have been the first to hit provider cabability
invocation in testing these changes, and so I found these few missing
methods on the client. They're just copied over from the other
capability hosts.
Calling capabilities on a provider also revealed that the wrong Machine
type was being pulled out of the funcspec args, so we had to correct
that too in order to get the capability calls working.
