hashicorp
terraform init to be explicit about when it's copying an existing module package dir vs. a direct download
Terraform Version
v1.2.4
Terraform Configuration Files
Any module that uses a remote source (eg git source) multiple times.
Debug Output
Downloading git::ssh://[email protected]/... for foo...
2022-07-12T12:49:09.522-0500 [TRACE] getmodules: fetching "git::ssh://[email protected]/..." to ".terraform/modules/foo"
Downloading git::ssh://[email protected]/... for bar...
2022-07-12T12:49:25.466-0500 [TRACE] getmodules: copying previous install of "git::ssh://[email protected]/..." from .terraform/modules/foo to .terraform/modules/bar
Expected Behavior
Per https://github.com/hashicorp/terraform/issues/29503#issuecomment-910850869 from @apparentlymart, Terraform downloads the remote source once, then copies the files for the other usages of the remote source. As a result, I would have expected the console output to say something like:
- "Copying ..."
- "Using ... from cache"
But you have to go to the trace output to see that Terraform is copying the files instead of downloading them from the remote source.
Actual Behavior
Console output says "Downloading git::ssh://[email protected]/... for bar..." for all of the modules even though download is not occurring after the source has been downloaded the first time.
Steps to Reproduce
terraform init
Additional Context
References
- https://github.com/hashicorp/terraform/issues/29503#issuecomment-910850869
Thanks for this. I agree that the output could be improved here. It might be a bit awkward to plumb the relevant UI writers in, but it's hopefully possible.
I believe this situation arose because a long time ago someone suggested that Terraform could "just" copy existing directories rather than re-downloading them, as an install-time optimization, and I agreed that seemed like a good incremental improvement that wouldn't drastically affect the design and so just plumbed it in to the lowest levels of the module installer where it was a relatively quick, low-risk win.
As @kmoe says, getting this surfaced up in the UI is likely to be more invasive. It would be great to make it accurate, in similar vein to how we've made the provider installer UI give more detailed feedback about how it's making use of existing caches, but I think also worth noting that we've been doing what we're currently doing for several years now with very few people noticing it, and so this feels to me more like a "nice to have" than a "must urgently fix", as we consider how to prioritize this relative to other work.
