This message was deleted.

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.