This allows the use case where installation of a plugin can simply say
to add `$GOPATH/bin/foo` to your terraformrc and the user can do that
verbatim. Additionally terraformrc files become portable for certain
environments which are self-contained.
I was hesitant at first about this because it diverges the syntax a bit
from our standard interpolation syntax. However, due to the special
nature of terraformrc and the strong use cases cited I'm okay with this.
- Currently the disable_checkpoint setting from $HOME/.terraformrc is never
respsected due to:
-- The runCheckpoint go routine being fired off prior to loading configuration
-- The config.Merge method not actually merging in the c2s settings
A user has at some point explicitly specified in .terraformrc that
overriding should take place (unlike PATH based overrides), so this
should log as INFO rather than WARN.
It is still of value for debugging purposes, however!
It is currently very easy to miss that a provider/provisioner has a
local override in your .terraformrc, leading to unexpected behaviour
that can be difficult to debug as no information is output about the
overrides.
This replaces this plugin system with the extracted hashicorp/go-plugin
library.
This doesn't introduce any new features such as binary flattening but
opens us up to that a lot more easily and removes a lot of code from TF
in favor of the upstream lib.
This will introduce a protocol change that will cause all existing
plugins to have to be recompiled to work properly. There is no actual
API changes so they just have to recompile, but it is technically
backwards incompatible.
Docker's API is huge and only a small subset is currently implemented,
but this is expected to grow over time. Currently it's enough to
satisfy the use cases of probably 95% of Docker users.
I'm preparing this initial pull request as a preview step for feedback.
My ideal scenario would be to develop this within a branch in the main
repository; the more eyes and testing and pitching in on the code, the
better (this would avoid a merge request-to-the-merge-request scenario,
as I figure this will be built up over the longer term, even before
a merge into master).
Unit tests do not exist yet. Right now I've just been focused on getting
initial functionality ported over. I've been testing each option
extensively via the Docker inspect capabilities.
This code (C)2014-2015 Akamai Technologies, Inc. <opensource@akamai.com>