Anton Tayanovskyy

I would add https://github.com/pulumi/pulumi-eks/issues/1220 here as a great example of a practical highly upvoted user issue. Note pulumi-eks provider is trying to do "vanilla" validation of its inputs of eks.Cluster,...

This is very tempting. Obviously feel like we must depend on it somewhere but if we don't that's a great change. QQ, when passing "variables" in Configure, they're still JSON-encoded...

Anything I can help with to unblock AWS tests?

This looks fantastic. Can we loop this through downstream bridged provider tests just in case to double-check that the bridge logic holds muster to parse these simpler config forms?

@justinvp any chance this can get a bit of review love? Also, how can we run the downstream tests to check bridged provider builds against this change, that'd help confidence...

That's an excellent question, that's also not covered by automatic downstream tests. I think last time I looked at azure-native it was reading from deprecated "variables" instead of "args" that...

Yeah that sounds right, I think for bridged providers what's persisted is not going to depend on how it's receiving the config, should be good there.

@EronWright brought up another interesting question on the strange Import(json=true) annotation in https://github.com/pulumi/pulumi-kubernetes/pull/3020 From what I can tell, Java SDK appears to generate this https://github.com/pulumi/pulumi-java/blob/main/pkg/codegen/java/gen.go#L449 to json-encode Provider configuration arguments...

Revisiting this PR, this could help remove a lot of difficulties in the bridge and even potentially remove config_encoding entirely, this is the right place to do the fix. @blampe...

I have a quick fix for that particular problem: https://github.com/pulumi/pulumi/pull/15526