Hi guys, We are currently rebuilding our pulumi infrastructure and switching from python to go. We are a little stuck to understand how and when to use

pulumi.ResourceOptions

and

pulumi.ResourceOption

and there difference. In our old Python stack, we always used the ResourceOptions and use that through all components. In Go, all components always wants

pulumi.ResourceOption

(

opts ...pulumi.ResourceOption

). What is the missing part we dont unterstood? :/ We studied the docs but there was not really helpful and finding go examples on github is very hard. Thanks for your help! :)

In JS/TS & Python, you pass in all the options as an object, hence

ResourceOptions

(plural). In Go, we were able to leverage the

variadic functions

feature indicated by the 3 dots. This means, you can pass every

ResourceOption

(singular) individually, one after the other separated by comma's. See this Go example on variadic functions.

Hi @limited-rainbow-51650, Thanks for your answer. In which case should we use the

pulumi.ResourceOptions

? From the python code, we could simply pass a variable via

opts

to own classes, use that opts directly and then change it to use it in their sub/child ressources. If we use

[]pulumi.ResourceOption

, I see no direct way to simply change one of the resourceOption without replacing everything or know the slice index for every part (parent, depends_on, etc..). Do you have some hints where i can find real pulumi configs in go that use the resourceOption with different parents or how

pulumi.ResourceOptions

are used correctly? Thanks :)

Hey @adorable-scooter-32619. The ResourceOptions function exists only to convert a

[]ResourceOption

into a "snapshot" of it so that you can look inside it. You should almost always use

ResourceOption

, not

ResourceOptions

, unless you need to look inside what a

...ResourceOption

actually means. For context, the

...ResourceOption

-based API is called a "functional option" in Go. It's a widely used pattern, but it has one major limitation: given

opts ...ResourceOption

, nobody except the implementors of the library can see what the

opts

mean. The

ResourceOptions

type and the accompanying

NewResourceOptions

function exist to address this limitation. We'll try to follow up with an API docs update to clarify this distinction.