But what I would love to be able to do is have my provider accept this generic depth map as input. Has anyone encountered this and/or found a solution/have any ideas on how I can?
I’ve searched through the code but I can’t seem to find anything that allows this to be supported.
From the perspective of the Terraform type system, an arbitrarily-nested map structure is really an object type describing the specific set of attributes and their individual types. The type system does not have the concept of “map of a mixture of types” because Terraform needs to track type information for expression validation.
However, when talking about type constraints rather than particular types there is the idea of the any constraint which is a placeholder for a single type chosen dynamically at runtime. In variables we can already use this in Terraform 0.12 as I think you’ve seen:
variable "example" {
type = any
}
These can then be validated using custom validation rules (experimental at the time of writing) to apply more complex validation rules than the type system can allow.
Terraform itself also allows attributes associated with resources in providers to be defined as using this any constraint, which in the internals of Terraform is called the “dynamic pseudo-type”. However, as you’ve seen the current SDK does not expose that capability because it’s trying to retain compatibility with Terraform 0.11 at the moment.
Once the SDK does support an any constraint, that would be the way to achieve the result you need here, possibly along with some custom validation rules written in Go that would be the provider-space analog to the variable validation rules feature I mentioned above.
The SDK team is tracking this particular feature in this issue:
This is great information, thank you so much for diving deep in your explanation.
I will follow along with the feature! My current plan to interact with this API will be to use a string attribute on the provider side, and jsonencode the any type variable.
This old topic was actually about dynamically-typed attributes rather than nested maps, despite the name, and the GitHub repository for the modern plugin framework (new since my last message) has an issue about supporting dynamically-typed attributes here:
If you do actually want nested maps – e.g. something like what you might write as map(map(string)) for an input variable – then that should already be possible to implement with the plugin framework, but I don’t know an example of an existing provider that’s already doing that because nested maps are relatively uncommon in provider schemas.