https://pulumi.com logo
#general
Title
# general
f

fresh-spring-82225

01/10/2024, 8:17 PM
Does anyone know how the pulumi cli decides what version of a plugin it needs? For aws, it doesn't seem to be determined by the version of @pulumi/aws in my package.json. I've got a lot of older versions of the plugin in my cache directory and it bothers me that I can't delete them without pulumi mysteriously downloading them why I run certain stacks.
Copy code
drwx------  6 kenji  staff   192B Jan  6 13:57 resource-aws-v5.35.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 13:57 resource-aws-v5.35.0.lock
drwx------  6 kenji  staff   192B Jan  6 14:03 resource-aws-v5.42.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 14:03 resource-aws-v5.42.0.lock
drwx------  6 kenji  staff   192B Jan  8 09:23 resource-aws-v6.13.2/
-rw-r--r--  1 kenji  staff     0B Jan  8 09:23 resource-aws-v6.13.2.lock
drwx------  6 kenji  staff   192B Jan 10 12:13 resource-aws-v6.13.3/
-rw-r--r--  1 kenji  staff     0B Jan 10 12:13 resource-aws-v6.13.3.lock
drwx------  6 kenji  staff   192B Jan  6 14:31 resource-aws-v6.14.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 14:31 resource-aws-v6.14.0.lock
drwx------  6 kenji  staff   192B Jan  6 14:34 resource-aws-v6.15.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 14:34 resource-aws-v6.15.0.lock
drwx------  6 kenji  staff   192B Jan  6 14:27 resource-aws-v6.17.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 14:27 resource-aws-v6.17.0.lock
drwx------  6 kenji  staff   192B Jan  9 18:18 resource-aws-v6.18.0/
-rw-r--r--  1 kenji  staff     0B Jan  9 18:18 resource-aws-v6.18.0.lock
drwx------  6 kenji  staff   192B Jan  9 18:35 resource-aws-v6.3.0/
-rw-r--r--  1 kenji  staff     0B Jan  9 18:35 resource-aws-v6.3.0.lock
drwx------  6 kenji  staff   192B Jan  6 13:35 resource-aws-v6.4.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 13:35 resource-aws-v6.4.0.lock
drwx------  6 kenji  staff   192B Jan  8 09:45 resource-aws-v6.8.0/
-rw-r--r--  1 kenji  staff     0B Jan  8 09:45 resource-aws-v6.8.0.lock
drwx------  6 kenji  staff   192B Jan  6 12:48 resource-aws-v6.9.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 12:48 resource-aws-v6.9.0.lock
g

green-stone-37839

01/10/2024, 8:47 PM
What is the version in your
package.json
? Short story is yes, it's determined by the version in your
package.json
f

fresh-spring-82225

01/10/2024, 8:58 PM
Here's an example of pulumi installing an old version of resource-aws, even when it says it should be using a new one
pulumi version v3.101.0
b

brave-angle-33257

01/10/2024, 10:04 PM
if you refresh/preview an older stack that was deployed with an older version, i believe it pulls it back in. If you were to deploy it again with the newer version specified, then i think it will no longer want/need the old one
f

fresh-spring-82225

01/10/2024, 10:23 PM
tried that, had no effect
one thing I do notice is that there's a reference to v6.9.0 via @pulumi/awsx when I run
yarn why
, but if I understand correctly it should be resolving to v6.17.0
Copy code
> yarn why @pulumi/aws
├─ @pulumi/awsx@npm:2.4.0
│  └─ @pulumi/aws@npm:6.17.0 (via npm:^6.9.0)
│
└─ pin-dash@workspace:.
   └─ @pulumi/aws@npm:6.17.0 (via npm:^6.17.0)
l

limited-rainbow-51650

01/11/2024, 9:24 AM
@fresh-spring-82225
awsx
is a component package which has its own dependency on the core
aws
package. Not so long ago, I extended our docs a bit with some more info: https://www.pulumi.com/docs/languages-sdks/javascript/#dependencies-on-provider-packages-within-component-packages You also have to make a distinction between
pulumi
operations which evaluate your infrastructure code and operations which use only the state information. This is how
pulumi
CLI acts in general (which is still a simplified representation): • `preview`: Pulumi CLI will use the new plugin version from your NodeJS
package.json
to read the existing resource state, calculate the diff & display the needed resource changes. The new version is not saved to state. • `refresh`: Pulumi CLI doesn't execute the user program, so will use the plugin version recorded in the state to read the resource state, and communicate with the real API to compare. When changes are accepted, some property values can be updated but no change in the version of the plugin binary will happen. • `up`: these proposed changes are applied using the new version of the provider. When some resources are scheduled for deletion, this will be done using the old version of the plugin. Other resource changes are handled using the new version of the plugin. The resource changes, together with the new plugin version, are now saved in the state. • `destroy`: Pulumi CLI doesn't execute the user program, hence the plugin version from the state is used to delete the resources. All state is deleted at the end. As you can read, multiple versions can still be at play when you just upgraded a provider version.
g

green-alligator-4238

01/13/2024, 4:53 PM
@limited-rainbow-51650 I can understand some of the logic behind this decision, but is there a way of forcing the use of single defined version or bumping/upgrading ‘legacy’ versions used in the past to a defined version/latest? I see the use of “^” in the link above, but that appears to be $latest (pls confirm either way). Scenario is when I want to remove the legacy versions from the env. Example when a specific version has security vulnerabilities etc. How do I force ‘only use x.y.z version’? Apologies if this is a dumb question - I’m a noob…
f

fresh-spring-82225

01/25/2024, 6:53 PM
@limited-rainbow-51650 I still don't fully understand, but I wanted to thank you for your response anyway