As I understand it (and correct me if I'm wrong), ...
# golang
s
As I understand it (and correct me if I'm wrong), part of the reason for using custom
Output
types is to track resource state, dependencies, etc. Can someone enlighten me as to why we might need to preserve such additional information across stacks? I'm thinking of a
StackReference
producing
Outputs
.
b
so that's almost it. The reason it's a custom type is because it's a future value, ie it's only known upon response from the upstream cloud providers API. An example of this is creating a simple EC2 instance, you don't actually know the instance ID until the instance is launched. So in that case the value is an
Output[string]
The reason we do this for stack references is pretty much the same, there are values in the dependent stack that we might not know until the stack is created/launched
s
OK, thanks for the clarification. I can see the need within a stack, but doing it across (or between) stacks is less clear. Seems like it would be cleaner just to check for null value in referencing stack and error out. (I'll be honest: Pulumi's custom types in Golang are the number one source of friction.)
b
yeah I understand that, i think we all recognise the need to provide some helper methods here to make life easier