Today, I forked a provider repository because it lacks a feature. Quickly implemented it and filed a PR upstream, so far so good.
But the experience in managing forked providers (or private providers in general) is, assuming you work with multiple coworkers, honestly dreadful:
- There are no (even closely) stable private registries outside of Artifactory which is bad if you’re using anything else (Gitlab’s registry only supports TF states and modules, the Nexus addon is third-party and only supports proxying, and AWS doesn’t offer anything). Having to set up Artifactory just to make a fork available to coworkers until changes are upstreamed is an absurd amount of effort.
- The documentation for the Terraform Cloud Private Registry says that one has to go through a Web API which is bad enough, but then doesn’t even provide curl commands one can use as an example, nor any kind of tooling to assist in the convoluted process
- There is no way to distribute overrides inside of a project that tell Terraform to download a provider artifact from somewhere else. One can use a TF CLI configuration file, but that has serious drawbacks on its own: developers have to remember to use TF_CLI_CONFIG_FILE if they do not wish to apply it to all Terraform projects they use, and since developers tend to have different directory structures to manage their projects you can’t keep a shared version that is able to pick up updates automatically (e.g. when you need to fork another provider). Also, updates to the fork have to be distributed to all developers by hand.
Please, try to find a better way instead of this monstrosity of workarounds and brittle hacks. It wouldn’t even be hard. Let us specify target ZIPs in our IaC repository required_provider blocks by exchanging the “source” attribute with something like “download_from” or whatever. I don’t care, but the current options are unsustainable and it makes contributing to the provider ecosystem very labor-intensive.