Plugin framework: Metadata method

Terraform Providers Plugin Development
1

I’m working with the new plugin framework 0.13.*, in comparison to <0.11 really good improvements. Only Metadata method confuses me a little bit:

  • in new examples the method uses ProviderTypeName and concatenate with datasource or resource name
    • the probability that the provider name will be changed is very low
    • maybe better be obvious with naming instead of generic approach, so it’s simpler to search and read (super_provider_example instead of res.ProvierTypeName + "_example", I just imagine how many _user or _organization resources can exist by different cloud providers)
  • since datasource and resource names are now closer to implementations, I have to “jump” between implementation and provider files to “construct” the resource name and understand what it does (maybe it’s just how my brain works :)).

:point_up: it’s some kind of the developer feedback from my side (even more reading-code-side). It might be I’m not aware about big plan (e.g. metadata generation will be used in LSP), where all these small changes makes more sense etc :wink:.

2

Hi @pavel-snyk! :wave: Thank you very much for the feedback.

You’re correct that most provider names will not change over time. The current provider and datasource/resource Metadata method setup is meant to ease development by acting as more of a “constant” in programming terms. On large providers, the previous managing of a large map of “full” names was tenuous, which was the main impetus to having datasource/resource naming be self-defined. The new problem was then that it was possible that contributions may omit the provider prefix without seeing other datasource/resource including it, so the provider name passing was introduced to reduce chances for development errors especially for those who may not be the most familiar with provider development.

The provider Metadata implementation (or using its value in each datasource/resource) is currently optional though, which would allow you to return the “full” name in each datasource/resource, if that is important for your development preferences. I have a personal feeling though that a lot of provider developers will get used to having shorter conventional filenames that align with just the datasource/resource name (if they are not doing that already), or at the very least there is typically an associated *_test.go file with the actual full datasource/resource name due to how the testing framework is implemented currently.

Aside: The framework could implicitly include the provider prefix automatically so it wouldn’t need to be specified at all in each datasource/resource. The first major version of the framework is, however, intentionally not trying to force practitioner breaking changes when migrating from terraform-plugin-sdk. There are existing examples of “unconventional” datasource names (which only match the provider name), such as http and external. Others may exist in the community. A future major version of the framework may force those names to be conventional, such http_request and external_program, but also given the ecosystem adoption of those utility data sources, the forced convention may never be implemented.

3

Thanks, @bflad.
Agree that it might be very beneficial for provider like awscc where a lot of code will be generated.
And yes, it’s some kind of the question without “right” answer :wink:.