Instead of evaluating and parsing a module source and version on
configuration loading, we now simply store the expression.
Decoding is now done during the graph-based configuration loading in the
module install node.
Variables can be deprecated through the `deprecated` attribute. If set the variable
will emit a diagnostic if a values is passed to it. This entails both root level and
module variables.
Outputs can be deprecated through the `deprecated` attribute as well. If set wherever
the value is used a diagnostic will be emitted. Root level outputs can not be deprecated.
The only acceptable usage of a deprecated output is another deprecated output (forwarding
the deprecation to the module user).
If modules not under your control have deprecation warnings you can add a `suppress_deprecations_warnigns`
attribute to the module call in question to silence any deeply nested warnings.
We've been gradually chipping away at how much we use go-getter for source
packages, because it's generally been a bit of a nightmare and sharing it
with other codebases means that any time someone wants to change something
we end up needing to find some way to prevent it breaking Terraform's
compatibility promises.
Here we make one further step: Terraform owns the "detectors" idea that
deals with source address normalization, and now always produces
fully-qualified addresses for go-getter to chew on only for the getting
and decompressing steps.
Retaining go-getter for the actual getting part is helpful because we can
then benefit from security fixes upstream, but Terraform owning the first
layer of parsing means that we can fix in place the definition of what
"module source address" syntax means, and thus we can avoid having
everything in this codebase indirectly depend on go-getter just because it
wants to parse module source addresses.
Now only the module installer actually depends indirectly on go-getter,
which finally disconnects go-getter's subtree from all of the remote state
backend dependency graphs.
Our package addrs ends up getting imported from just about ever other
package in Terraform, because it contains the types we use to talk about
various different kinds of objects. Therefore we typically try to keep its
transitive dependency graph relatively small, because anything it depends
on becomes an indirect dependency of nearly everything else.
A while back we moved the module source address models into package addrs,
which also brought with them the code for parsing strings to produce those
addresses. Unfortunately, remote module source addresses are defined using
the external dependency go-getter, which is pretty heavy itself and also
brings with it numerous other external dependencies such as the AWS SDK,
the Google Cloud Platform SDK, etc.
Since only relatively few packages actually need to _parse_ source
addresses -- with most either not caring about them at all or only
consuming addresses that were already parsed by someone else -- we'll
move the parser functions into their own package, while keeping the
resulting address types in package addrs.
This does still retain the package addrs dependency on external module
github.com/hashicorp/terraform-registry-address, which is not ideal but
that one at least has a relatively shallow dependency subgraph, so there's
not so much urgency to tidy that one.
* [testing framework] prepare for beta phase of development
* [Testing Framework] Add module block to test run blocks
* [testing framework] allow tests to define and override providers
Previously we ended up losing all of the error message detail produced by
the registry address parser, because we treated any registry address
failure as cause to parse the address as a go-getter-style remote address
instead.
That led to terrible feedback in the situation where the user _was_
trying to write a module address but it was invalid in some way.
Although we can't really tighten this up in the default case due to our
compatibility promises, it's never been valid to use the "version"
argument with anything other than a registry address and so as a
compromise here we'll use the presence of "version" as a heuristic for
user intent to parse the source address as a registry address, and thus
we can return a registry-address-specific error message in that case and
thus give more direct feedback about what was wrong.
This unfortunately won't help someone trying to install from the registry
_without_ a version constraint, but I didn't want to let perfect be the
enemy of the good here, particularly since we recommend using version
constraints with registry modules anyway; indeed, that's one of the main
benefits of using a registry rather than a remote source directly.
Now that we (in the previous commit) refactored how we deal with module
sources to do the parsing at config loading time rather than at module
installation time, we can expose a method to centralize the determination
for whether a particular module call (and its resulting Config object)
enters a new external package.
We don't use this for anything yet, but in later commits we will use this
for some cross-module features that are available only for modules
belonging to the same package, because we assume that modules grouped
together in a package can change together and thus it's okay to permit a
little more coupling of internal details in that case, which would not
be appropriate between modules that are versioned separately.
It's been a long while since we gave close attention to the codepaths for
module source address parsing and external module package installation.
Due to their age, these codepaths often diverged from our modern practices
such as representing address types in the addrs package, and encapsulating
package installation details only in a particular location.
In particular, this refactor makes source address parsing a separate step
from module installation, which therefore makes the result of that parsing
available to other Terraform subsystems which work with the configuration
representation objects.
This also presented the opportunity to better encapsulate our use of
go-getter into a new package "getmodules" (echoing "getproviders"), which
is intended to be the only part of Terraform that directly interacts with
go-getter.
This is largely just a refactor of the existing functionality into a new
code organization, but there is one notable change in behavior here: the
source address parsing now happens during configuration loading rather
than module installation, which may cause errors about invalid addresses
to be returned in different situations than before. That counts as
backward compatible because we only promise to remain compatible with
configurations that are _valid_, which means that they can be initialized,
planned, and applied without any errors. This doesn't introduce any new
error cases, and instead just makes a pre-existing error case be detected
earlier.
Our module registry client is still using its own special module address
type from registry/regsrc for now, with a small shim from the new
addrs.ModuleSourceRegistry type. Hopefully in a later commit we'll also
rework the registry client to work with the new address type, but this
commit is already big enough as it is.
This is part of a general effort to move all of Terraform's non-library
package surface under internal in order to reinforce that these are for
internal use within Terraform only.
If you were previously importing packages under this prefix into an
external codebase, you could pin to an earlier release tag as an interim
solution until you've make a plan to achieve the same functionality some
other way.
