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

Yes - you do.  That said, I would have expected we were downloading it if needed.

cc <@UB27BHS4B> in case he has thoughts on this.

following up <@UB27BHS4B> - is this related to the same issue <https://github.com/pulumi/pulumi/issues/2608> ?  Since we use a portable docker container with pulumi embedded (and usually the latest CLI and plugins) if the system isn’t supposed to auto-download, that would make it quite a bit more challenging for us.. I assume we’d to have every version ever released installed in the container.  Can you clarify?

The issue you linked only happens if you have a non-standard Node project setup - is that the case inside your Docker container?

yes for the linked issue it’s as we discussed previously where the package.json is above the project folder

it’s the same setup for this new issue we’re seeing where the destroy of an older stack fails because the plugin isn’t installed

for the linked issue i wrote code to parse the stack contents and prune old plugins as part of our pipeline

for today’s issue, i dont know what the fix would be - which is why I’m inquiring

then yes. The only plugins you need to install are the ones explicitly mentioned in your npm package-lock.json.

ones required by your state ("old" resources) should be downloaded on-demand.

hmm.. ok that didn’t seem to happen then per the issue report I received.. it didn’t appear to be downloaded automatically

i’ll just keep an eye on it and see if it crops up again, maybe the user did something weird

hi <@UB27BHS4B> ok, so at least i’ve narrowed this down a bit - I have our pipeline using Pulumi in a docker container.  That container usually only has the latest plugins installed.  For our automated teardown, i’ve been doing a `pulumi refresh` beforehand, seems to be a good idea to correct any drift, but if the version is old, then it fails.  Is this supposed to automatically install the old plugin in this case?

I do have the “nonstandard” setup as described in this issue: <https://github.com/pulumi/pulumi/issues/2608> - am I correct in assuming that once #2608 is solved that this issue will likely be solved as well?  In the meantime, it appears the destroy works correctly.. so if I remove the “refresh” step on the teardown, i can probably work around it

Yes, that’s correct, although we could probably do better with `refresh`. Can you open an issue for that?

ok thanks, I’ll post the pastebin log and explain the issue then

<https://github.com/pulumi/pulumi/issues/2669> :+1: