What’s the easiest (lowest friction) alternative to a dynamic provider for Go? I have an API I need to work with that does not have a Pulumi package, and I’d prefer to avoid needing to define a whole package for it just to make some progress.

the new pulumi command provider: https://www.pulumi.com/registry/packages/command/

@billowy-army-68599 thanks. If I am reading this correctly, I basically have to create a separate program that I can exec (either by calling something like

curl

or by writing my own Python/bash script or what not) - I can’t just define a function in Go and have it be executed. Is that right? And one more follow up - in the Command examples, the GithubLabel one is probably the closest. It has the note on

local.Command

missing

diff/update/read

. Does this mean that it will apply updates to the

Command

resource (e.g. if the commands change) by first doing the

delete

and then doing a

create

again, or something else? Just trying to understand how it fits into the overall lifecycle.

that's right yeah, for the github one, you'd need to define your own scripts for diff/update/read

I’m not sure I follow - I think I’d need to define my own scripts for

create

and

delete

, yes? There’s no way for me to define scripts for

diff/update/read

, as that isn’t supported yet by

local.Command

?

ah yes, that's my mistake, you're right. sorry about that

OK, so with that in mind, let’s take the

GithubLabel

example from the doc. If I were to make a change to that resource (e.g. change the

name

in

LabelArgs

), would Pulumi automatically do a

delete

on the old one and

create

on the new one? i.e. it would handle the lifecycle, it would just do it “less efficiently” (i.e. always as a

delete-create

rather than as

update

)

i believe so, yes

OK - thank you. Am I actually saving a lot of pain (given I’ll need to create external scripts now) or should I just go and create a package for this?

ultimately you can run anything, you could create go binaries and run them!

Yes 🙂 I’m just wondering if the effort of creating all of these external things (e.g. a script/program for create, one for delete, etc) is going to end up being less work than creating an actual package