Martin Atkins

Although it doesn't necessarily need to be part of the solution here, I want to note a related use-case that I've heard before: When Terraform requests temporary credentials, it can...

Hi @YuriGal! Thanks for sharing this use-case. The important design consideration here is that existing modules unfortunately expect to be able to create new files inside `path.module`, and thus each...

To be concrete about it, it is currently possible to write something like the following in a Terraform module and have it work, and so we are bound to keep...

This (more reasonable, more common) pattern must also keep working: ```hcl resource "aws_s3_bucket_object" "example" { bucket = "example" key = "anything" source = "${path.module}/bucket-content/anything" } ``` In this case, `bucket-content/anything`...

`path.module` is just a static string that gets interpolated into the path like any other, so Terraform must decide what `path.module` evaluates to once for the entire module, not separately...

Indeed... the only situation where Terraform Core is directly interacting with the filesystem is in function calls like `file("${path.module}/foo.txt")` and even in that case the interpolation of `path.module` as a...

Unfortunately we know that the existing uses are prevalent enough that we cannot use the lack of documentation as justification for the breaking change. The following language in our compatibility...

It seems to me that whether it's safe/correct to reuse the same directory for multiple instances of the same module is a property of the module itself rather than a...

Thanks for reporting this, @bentterp. Indeed, it does seem like the strip markers and the flush-parsing mode are interacting poorly here. This seems to be a bug upstream in HCL,...

The current behavior is protected by the v1.x compatibility promises and so we cannot change the existing behavior without introducing new syntax to opt into it. Therefore this requires further...