Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
## Problem When running `go list -m` in a provider upgraded to use bridge v3.93.1 you will get this error: ``` go: github.com/hashicorp/terraform-provider-tls@v0.0.0: invalid version: unknown revision v0.0.0 go: github.com/hashicorp/terraform-provider-tls/shim@v0.0.0-00010101000000-000000000000: invalid version: unknown revision 000000000000 go: github.com/terraform-providers/terraform-provider-random/randomshim@v0.0.0-00010101000000-000000000000: invalid version: unknown revision 000000000000 ``` Ian called this out in #2473 (comment). My response there is true in the sense that providers _do still build_ just fine -- `go build`, `go test` etc. don't touch these unused modules. The caveat I overlooked is that some IDE integrations (or more specifically any tooling built around `go list`) _will_ try to resolve all of these direct and indirect dependencies. When we consolidated modules, we moved `replace` directives for these shims out of the test module and into the root module. ## Option 0: Bring back all the modules I beg you not to do this but I do want to call it out as an option if the team would prefer it. I outline two more "idiomatic" options below. ## Option 1: Handle replacements in the consumer As a reminder, the `replace` directive only applies to the module where it's defined -- primarily to keep Go's minimal version selection algorithm simple and fast, but also to give downstream modules complete control of their builds. Hence `replace` is best suited for temporary overrides, for example to point at a local branch. Permanent `replace` directives do happen and we use them quite a lot, though. If a module truly needs a permanent `replace` to work properly (which, to be clear, should be avoided!), its consumers need to mirror the same `replace`. In other words, Option 1 is to not make any changes. Downstream projects can resolve this issue by copying these lines into `go.mod`: ``` replace github.com/hashicorp/terraform-provider-tls/shim => github.com/pulumi/pulumi-terraform-bridge/v3/pkg/pf/tests/internal/tlsshim v0.0.0-20241025174446-f865647b85ed replace github.com/hashicorp/terraform-provider-tls => github.com/hashicorp/terraform-provider-tls v1.2.1-0.20210201152640-49d7590ccf3f replace github.com/terraform-providers/terraform-provider-random/randomshim => github.com/pulumi/pulumi-terraform-bridge/v3/pkg/pf/tests/internal/randomshim v0.0.0-20241025174446-f865647b85ed ``` Clearly this is burdensome. For a real-world data point, this is the same strategy adopted by the k8s ecosystem and it has made dependency management with k8s notoriously painful. We should not do this. ## Option 2: Fork instead of abusing modules `tlsshim` and `randomshim` are their own modules because they intentionally trick the compiler into exposing internal terraform packages. This `internal` import is only legal if your module is identified as `github.com/terraform-providers/terraform-provider-random`: https://github.com/pulumi/pulumi-terraform-bridge/blob/7dfbcd601c7392fbf04bdec4c83a56b1ef115bc6/pkg/pf/tests/internal/randomshim/shim.go#L17-L24 This is hacky but it matches the guidance we gives to users, and it is _workable_ as long as the module consuming these shims doesn't have downstream consumers of its own. This is the case with most providers, but tfbridge is different because it _is_ meant to be consumed as a library. A more typical remedy for consuming private types is to fork the dependency and expose what you need. We could fork these two repositories under the `pulumi` org, but new repos come with their own overhead. Instead, I opted to simply check-in the upstream random and tls providers. I preserved the commits we were previously pinned to ([c6e90de46687](hashicorp/terraform-provider-random@c6e90de) and [afdd54107aba](hashicorp/terraform-provider-tls@afdd541), respectively) so licensing is unaffected. This way our `go.mod` will reflect a dependency on a public module that is still consumable downstream (e.g. `terraform-provider-random`), and we will use forks that expose the internals when testing. This PR implements Option 2.
- Loading branch information
