Fraser Waters

> one option here for the near term would be to make this a warning instead of an error, and to use the provider as established in the program execution...

Little hesitant to allow init to not error for already existing stacks. Creating new stacks is the common case here and most users want an error if they accidentally try...

Ah yes sorry, I'd suggest trying to use `pulumi stack select --create` and `pulumi config cp`. We could possibly add a `--select` flag to init (sort of mirror of the...

``` pulumi-docker = "^4.1.1" pulumi-aws = "^5.34.0" ``` Both of those packages just ask for `pulumi>=3.0.0,

> I would advocate for a solution that allows the provider to produce unknowns when the invoke call cannot be made. There's two issues with that. First is that invokes...

> I'm advocating for having the provider catch the error and then synthesize unknown values, as shown in the example. Your example is pretty unique in that these are overlay...

> is there codegen for invokes? Yes, most invokes are just exposed to users directly via codegen. Which is why adding options like FailOnPreview is a bit awkward, these things...

In normal setups running these binaries from PATH is nearly always indicative of a mistake. Even during development where we do frequently build the plugins to ~/go/bin (on PATH) and...

Ah the symlinks here are complicating things. We've got a number of other official setups (like homebrew) using symlinks in some shape that the plugin lookup code is already having...

> but we had to install pulumi resource plugins via nix instead of using pulumi as the pre-compiled binaries wouldn't run on nixos without being patched First I've heard of...