Fraser Waters

Still need to fix up the mock support for this, but ready to start looking at for the rest of the changes.

We're phasing out support for non-project mode so these tests probably aren't worth writing now.

Currently the only "global" place the current stack is pulled from is in ~/.pulumi/workspaces, but that's not easy to write to (the folder names are all hashed). It doesn't seem...

> If we want to make adjustments here without touching all of the providers, one approach might be to add a pulumi.autoname() API to our SDKs. This API could leave...

@mikhailshilkov thanks for that didn't realize it was so varying, makes a lot of sense to just leave this in the providers then and deal with that we're going to...

@lunaris has done some initial investigation into this area, we definitely want to improve the grpc errors so that they look "clean" to users, rather than containing irrelevant grpc details.

Looks like this hasn't been needed since Pulumi 1.1, not sure why we didn't take it out before? Probably worth having an old timer like @justinvp or @pgavlin to sanity...

> Perhaps that's handled in the engine not here in codegen? It is handled in the engine, was changed all the way back in pulumi 1.1.

The big blocker for this to _just work_ is that the engine doesn't support importing provider resources. They need to already exist in the stack. I'm not sure it's worth...

@t0yv0 pointed out that schema loading should still respect PULUMI_DEBUG_PROVIDERS. Be confusing if you were using a new provider exe to debug against but all the schema checking was done...