initwd: Error message for local paths escaping module packages
Our module installer has a somewhat-informal idea of a "module package",
which is some external thing we can go fetch in order to add one or more
modules to the current configuration. Our documentation doesn't talk much
about it because most users seem to have found the distinction between
external and local modules pretty intuitive without us throwing a lot of
funny terminology at them, but there are some situations where the
distinction between a module and a module package are material to the
end-user.
One such situation is when using an absolute rather than relative
filesystem path: we treat that as an external package in order to make the
resulting working directory theoretically "portable" (although users can
do various other things to defeat that), and so Terraform will copy the
directory into .terraform/modules in the same way as it would download and
extract a remote archive package or clone a git repository.
A consequence of this, though, is that any relative paths called from
inside a module loaded from an absolute path will fail if they try to
traverse upward into the parent directory, because at runtime we're
actually running from a copy of the directory that's been taking out of
its original context.
A similar sort of situation can occur in a truly remote module package if
the author accidentally writes a "../" source path that traverses up out
of the package root, and so this commit introduces a special error message
for both situations that tries to be a bit clearer about there being a
package boundary and use that to explain why installation failed.
We would ideally have made escaping local references like that illegal in
the first place, but sadly we did not and so when we rebuilt the module
installer for Terraform v0.12 we ended up keeping the previous behavior of
just trying it and letting it succeed if there happened to somehow be a
matching directory at the given path, in order to remain compatible with
situations that had worked by coincidence rather than intention. For that
same reason, I've implemented this as a replacement error message we will
return only if local module installation was going to fail anyway, and
thus it only modifies the error message for some existing error situations
rather than introducing new error situations.
This also includes some light updates to the documentation to say a little
more about how Terraform treats absolute paths, though aiming not to get
too much into the weeds about module packages since it's something that
most users can get away with never knowing.
2021-05-22 00:28:20 +02:00
|
|
|
module "child" {
|
|
|
|
|
# NOTE: For this test we need a working absolute path so that Terraform
|
|
|
|
|
# will see this a an "external" module and thus establish a separate
|
|
|
|
|
# package for it, but we won't know which temporary directory this
|
|
|
|
|
# will be in at runtime, so we'll rewrite this file inside the test
|
|
|
|
|
# code to replace %%BASE%% with the actual path. %%BASE%% is not normal
|
|
|
|
|
# Terraform syntax and won't work outside of this test.
|
|
|
|
|
#
|
|
|
|
|
# Note that we're intentionally using the special // delimiter to
|
|
|
|
|
# tell Terraform that it should treat the "package" directory as a
|
|
|
|
|
# whole as a module package, with all of its descendents "downloaded"
|
|
|
|
|
# (copied) together into ./.terraform/modules/child so that child
|
|
|
|
|
# can refer to ../grandchild successfully.
|
|
|
|
|
source = "%%BASE%%/package//child"
|
|
|
|
|
}
|