Hello meow party I feel like I'm searching for the wrong words. When I see an incoming change that downgrades a provider version, even though I have the matching higher version installed, is there anything I can do about it? The model I'm thinking of is like terraform provider version constraints, but I can't find anything matching terms like "provider version constraint" or "plugin version requirement" or permutations of those. Anybody know if something like that exists?

~ pulumi:providers:kubernetes: (update)
                [id=57bfa5cb-9c4d-4bb9-87b4-8fa3f6a03f9a]
                [urn=urn:pulumi:something-staging::my-fancy-thing::my:FancyThing$my:FancyThing$pulumi:providers:kubernetes::something-staging]
              ~ version: "4.11.0" => "4.8.0"

It's worth checking the provider version in

pulumi about

, to ensure the dependency pulumi uses is actually the version you expect

you might want to look into locking tools, like pipenv, poetry, or pip-tools

This is very helpful! And also somewhat surprising! We're using a single

pyproject.toml

with

hatch

for everything in the working tree. I'm guessing this may be a case where the version constraints at that level need to be tighter or more explicit. Is specifying the python package version supposed to be sufficient for having a stable plugin version?

With hatch, yes you need to make the requirements tighter as it doesn't have a locking implementation

Excellent, thank you @dry-keyboard-94795 !

I'd probably do explicit pins for Pulumi provider deps