https://pulumi.com logo
Join SlackCommunities
Powered by
This message was deleted.
# general
s
This message was deleted.
l
If it helps make you feel better about your current state.. we have a policy here that providers must be passed in to all resources, every time. We had too many conflicts and too much work-around code when using the default provider some times, and explicit providers other times.
f
Yeah, I can see how that could be useful. Do you have code that enforces that policy somehow?
l
I've been planning to write a linter to run pre-merge to help with code reviews, but no, not yet.
f
gotcha, thanks.
Your comment makes me want to rephrase my original request... I guess it's not so much that I don't want to have to pipe in the provider everywhere, but that I want to make sure that all the resources are using the same provider consistently.
l
Yes, that's the nub.
f
being explicit certainly has benefits 😂 Thanks @little-cartoon-10569
l
Aside: We find it helpful to name the providers after the scope they provide, rather than the service that provides it. So instead of "aws_default" or "region_eu", we use "core_network", "dev_sandbox", etc. That helps with the self-documetation, etc. YMMV
f
ah, useful!
b
I'm not sure I'd necessarily recommend this, but you could use a transformation on the resources to set the provider... https://www.pulumi.com/docs/intro/concepts/resources/#transformations
transformations can violate the principal of least surprise though
f
also interesting... thanks @billowy-army-68599
I've been investigating a resource transformation to add a custom provider to my resources, and it appears to be working well. However, now I've encountered the providers used for "invocations" (e.g., something like 
pulumi_aws.dynamodb.get_table
). These aren't touched by stack transformations, requiring manual intervention again. Is there a corresponding global transformation hook for invocations that I've overlooked? Is this divergence intentional?
Open in Slack
PreviousNext
Powered by