No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

They do not affect non-resources:
&gt; Transformations can also be applied in bulk to many or all resources in a stack by using Stack Transformations, which are applied to the root stack resource and as a result inherited by all other resources in the stack.

Well darn. Is there some way to set InvokeOptions on a mass scale besides transforms?

Only via your preferred language's normal methods. Use a base object, wrap the call to the Pulumi functions in some of your own code, something like that.

Changing the provider in a transformation is fairly risky. It is quite likely that eventually, you'll have an exception to the rule, and your transformation will override it. You'll spend a while tracking that down...

You might consider requiring provider to always be passed in, and creating a transformation that throws an exception if it's not. That should be safer.

I would tend to agree, but this is part of a dynamic system where one sets the provider for a given instance of the stack. So configuration like this needs to trickle down automatically without changing the underlying Pulumi code.

You can still make requirements on the developers of your system. Rather than allowing them to use aws.s3.get_bucket(), you can require them to use yourorg.s3.get_bucket(), which calls aws.s3.get_bucket() with the correct opts.

Yep, I think that sounds like a good option for now. Appreciate the tip!