This message was deleted.

@tall-librarian-49374 any thoughts here? It is not desirable for users to manipulate or read config via this api. The goal of this api is really to be able to whole sale save or write a pulumi.stack.yaml/json. Any manipulation of config should happen through the config APIs, as those will perform all necessary encryption/decryption.

well in this scenario I think if they

GetStackSettings

and then

SaveStackSettings

with the same object after making any changes (even if those changes weren't to config) they will possibly have issues. If it was JSON, the save will try to serialize

JsonElement

which I think will be fine since

System.Text.Json

can do that out of the box. But if it is YAML than they may lose some context since everything is deserialized as a

string

and will then be serialized as such

It sounds a bit odd to get different behavior depending on the source type JSON/YAML. I guess I’d expect the in-memory representation to operate the same set of primitives as our protobuf serialization in https://github.com/pulumi/pulumi/tree/master/sdk/dotnet/Pulumi/Serialization (which includes JsonElement and immutable dictionaries)

so can you explain what you think the resulting dictionary from each format should be? That means I need to do some additional work after deserializing from JSON or YAML to get to the target dictionary.

I wouldn’t spend too much time on this right now if that’s an “internal” API. Unless this is required for correctness on load/save.

that's the issue - it is required for Get/Save of ProjectSettings and StackSettings

I agree that this API isn't that important. I think it would be fine for V1 to say that if you want to work with stack settings or project settings, you have to do it via interacting with the files directly in the

WorkDir

.

So if it is anything other than a plain string or secure string, we could just not deserialize it?

I guess I’m suggesting not to implement the project settings or stack settings APIs for the time being.

Hmmmm I think we can do that. It doesn’t look like anything else depends on them. It’s your call

Let's go ahead and defer on implementation here in favor of making progress on end to end scenarios.