Unable to programmatically select framework version

[jacobbednarz]

Module version

v1.4.1

Within the SDKv2, the meta package exposes SDKVersionString which allows library consumers to use this value programmatically (most commonly in the user agent). In my specific case, we use it for tracking adoption of resources and when bugs arise, help identify the impacted consumers.

However, the plugin framework doesn't have this (that I can find) and I would love to see it back again. In the SDKv2, this is a string value that is meant to be updated on release but currently isn't (separate issue at hashicorp/terraform-plugin-sdk#1257 but may be related for next steps and whether this should remain a thing).

[bflad]

Hi @jacobbednarz 👋 Thank you for raising this. Since this issue does not seem to suggest existing terraform-plugin-framework functionality that is not working as expected, I'm going to relabel this issue as an enhancement.

In my specific case, we use it for tracking adoption of resources and when bugs arise, help identify the impacted consumers.

To dive a little further in this use case, is there a particular reason why the framework's versioning, over the provider's own versioning, is important for this observability? Is this so you can determine whether a resource was implemented using terraform-plugin-sdk versus terraform-plugin-framework?

If getting the framework versioning is critical, Go module code such as provider code, can fetch this information automatically using Go standard library functionality. The runtime/debug.ReadBuildInfo() function returns the Deps field which contains module paths and version information. This is how Terraform core, for example, is able to log "interesting" dependencies: https://github.com/hashicorp/terraform/blob/07b814c030daae39dea764571bef9cecf26e49be/version/dependencies.go#L8-L46

Does using that runtime/debug information satisfy your use case?

[jacobbednarz]

Since this issue does not seem to suggest existing terraform-plugin-framework functionality that is not working as expected, I'm going to relabel this issue as an enhancement.

thanks! I wasn't sure on the expected compatibility with SDKv2 so I'll keep this in mind for the future too.

Is this so you can determine whether a resource was implemented using terraform-plugin-sdk versus terraform-plugin-framework?

correct. furthermore, if an issue is identified in one of the plugin types, we can assess how many others are impacted by the potential bug.

The runtime/debug.ReadBuildInfo() function returns the Deps field which contains module paths and version information.

I mentioned it in the linked issue as well but will post here for posterity too, I'm happy swapping to this method if it is the blessed approach. My concern was that because it wasn't getting used/exported that way that we were reaching into internals that we shouldn't and relying on an unstable interface.

[bflad]

Hi again, @jacobbednarz! It looks like you may have tried out the new way in the latest provider release. Is it working okay for you?

[jacobbednarz]

i have thank you very much. with help from yourself and @austinvalle, this was sorted in the linked SDK issue.

given the vibe is that you don't want to expose this via a helper method and instead favour the runtime/debug.ReadBuildInfo() approach, I'm happy to close this off.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.