Commit Graph

70 Commits

Author SHA1 Message Date
James Bardin 5f053a2e64 refactor GetProvider
Get provider needs to be provided with the plugin protocol version,
because it can't be imported here directly.

The plugin url types and methods were confusing; replace them with a few
functions to format the urls.
2017-06-09 14:03:59 -07:00
James Bardin 8ad67991a5 check protocol version on plugins
Verify that the plugin we're requesting has a compatible protocol
version.
2017-06-09 14:03:59 -07:00
James Bardin fdeb3d929c Add Versions.Sort
Sort versions from newest to oldest.
2017-06-09 14:03:59 -07:00
Martin Atkins 04bcece59c plugin/discovery: handle the -Xn suffix used by auto-installed plugins
This is used to mark the plugin protocol version. Currently we actually
just ignore this entirely, since only one protocol version exists anyway.
Later we will need to add checks here to ensure that we only pay attention
to plugins of the right version.
2017-06-09 14:03:59 -07:00
Martin Atkins e3401947a6 plugin/discovery: PluginRequirements can specify SHA256 digests
As well as constraining plugins by version number, we also want to be
able to pin plugins to use specific executables so that we can detect
drift in available plugins between commands.

This commit allows such requirements to be specified, but doesn't yet
specify any such requirements, nor validate them.
2017-06-09 14:03:59 -07:00
James Bardin 044ad5ef59 rename some Constraints methods per code review 2017-06-09 14:03:59 -07:00
James Bardin 211f5b5d6e add test for newestVersion 2017-06-09 14:03:59 -07:00
James Bardin 46190590cb change []*Version to []Version
Versions are used as values, so don't keep them as pointers here
2017-06-09 14:03:59 -07:00
James Bardin a547e7c2f0 add releases version listing test 2017-06-09 14:03:59 -07:00
James Bardin 2749946f5c basic plugin getter
Add discovery.GetProviders to fetch plugins from the relases site.

This is an early version, with no tests, that only (probably) fetches
plugins from the default location. The URLs are still subject to change,
and since there are no plugin releases, it doesn't work at all yet.
2017-06-09 14:03:59 -07:00
James Bardin fa49c69793 expose Version.NewerThan
NewerThan is useful outside of the package
2017-06-09 14:03:59 -07:00
James Bardin 7d2d951f27 Rename VersionSet to Constraints
VersionSet is a wrapper around version.Contraints, so rename it it as
such.
2017-06-09 14:03:59 -07:00
Martin Atkins cfc08ae7e3 plugin/discovery: provide an AllVersions set
Various implied dependencies will accept all versions, so this is
convenient for populating dependency data structures for such implied
dependencies.
2017-06-09 14:03:59 -07:00
Martin Atkins a1e29ae290 plugin/discovery: use go-version instead of semver
The semver library we were using doesn't have support for a "pessimistic
constraint" where e.g. the user wants to accept only minor or patch
version upgrades. This is important for providers since users will
generally want to pin their dependencies to not inadvertantly accept
breaking changes.

So here we switch to hashicorp's home-grown go-version library, which
has the ~> constraint operator for this sort of constraint.

Given how much the old version object was already intruding into the
interface and creating dependency noise in callers, this also now wraps
the "raw" go-version objects in package-local structs, thus keeping the
details encapsulated and allowing callers to deal just with this package's
own types.
2017-06-09 14:03:59 -07:00
Martin Atkins 9b4f15c261 plugin: move Client function into plugin, from plugin/discovery
Having this as a method of PluginMeta felt most natural, but unfortunately
that means that discovery must depend on plugin and plugin in turn
depends on core Terraform, thus making the discovery package hard to use
without creating dependency cycles.

To resolve this, we invert the dependency and make the plugin package be
responsible for instantiating clients given a meta, using a top-level
function.
2017-06-09 14:03:59 -07:00
Martin Atkins bcd395e6bd plugin/discovery: Allow overriding the paths of certain plugin names
The .terraformrc file allows the user to override the executable location
for certain plugins. This mechanism allows us to retain that behavior for
a deprecation period by treating such executables as an unversioned
plugin for the given name and excluding all other candidates for that
name, thus ensuring that the override will "win".

Users must eventually transition away from using this mechanism and use
vendor directories instead, because these unversioned overrides will never
match for a provider referenced with non-zero version constraints.
2017-06-09 14:03:59 -07:00
Martin Atkins 551bc9c4a4 plugin/discovery: build plugin clients
These new methods ClientConfig and Client provide the bridge into the
main plugin infrastructure by configuring and instantiating (respectively)
a client object for the referenced plugin.

This stops short of getting the proxy object from the client since that
then requires referencing the interface for the plugin kind, which would
then create a dependency on the main terraform package which we'd rather
avoid here. It'll be the responsibility of the caller in the command
package to do the final wiring to get a provider instance out of a
provider plugin client.
2017-06-09 14:03:59 -07:00
Martin Atkins 0a08214a74 plugin/discovery: SHA256() method to get the hash of each plugin
This will be used later to verify that installed plugins match what's
available on the releases server.
2017-06-09 14:03:59 -07:00
Martin Atkins a94e9a4362 plugin/discovery: find plugins in a given set of directories
For now this supports both our old and new directory layouts, so we can
preserve compatibility with existing configurations until a future major
release where support for the old paths will be removed.

Currently this allows both styles in all given directories, which means we
support more variants than we actually intend to but this is accepted to
keep the interface simple such that we can easily remove the legacy
exception later. The documentation will reflect only the subset of
path layouts that we actually intend to support.
2017-06-09 14:03:59 -07:00
Martin Atkins 39deb1ff6b plugin/discovery: helpers for wrangling plugin versions
With forthcoming support for versioned plugins we need to be able to
answer questions like what versions of plugins are currently installed,
what's the newest version of a given plugin available, etc.

PluginMetaSet gives us a building block for this sort of plugin version
wrangling.
2017-06-09 14:03:59 -07:00