Closed t0yv0 closed 1 week ago
Instead of keeping Set
as a method on shim.SchemaMap
(which is mostly implemented by paniking), what do you think about introducing a more targeted fix to address this specific problem? For example:
// sdk-v2/schema.go
func XSetSchemaMap(m shim.SchemaMap, key string, value *schema.Schema) {
m.(v2SchemaMap)[key] = value
}
This would let us solve the problem (aws not compiling) without re-expanding the shim.SchemaMap
interface.
@iwahbe since it sounds like we want shim.SchemaMap
to not be mutable, is there a different way we should be doing this in aws
?
@iwahbe since it sounds like we want
shim.SchemaMap
to not be mutable, is there a different way we should be doing this inaws
?
That is a great question, and the one I should have started with. I think the correct thing to do is to inject the "name"
field at the schema level directly, instead of messing with the TF level as a side channel.
I opened https://github.com/pulumi/pulumi-aws/pull/4086 to do just that.
What happened?
Unfortunately there is a small set modification going on in resources.go so Set cannot be dropped yet:
Example
See above.
Output of
pulumi about
N/A
Additional context
N/A
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).