This message was deleted.

That seems to have all the information in it. You are creating two stack reference objects referring to the same stack. This isn't allowed. You need to pass the stack reference around.

it would seem like it would be easy to find. It does not appear to be - unless my IDE i just not able to do text search lol We have a mono repo, with multiple projects in it. Because of a deficiency of the python/pulumi combo, we have to do this:

import sys
sys.path.append("../../")
from account.__main__ import Outputs

Where Outputs are an enum of the output keys. I'm not sure how else to import something from a sister python project, or if this is the culprit.

If I'm understanding the problem correctly, the other project isn't relevant to solving the problem. In the current project, you're constructing the same StackReference object twice. This isn't allowed. It's a local error, not related to the project that contains the stack.

ok i will refactor some things and try to simplify. Is there a reason why a singleton pattern wouldn't work with python here? That would be a much easier approach than to pass stacks around to all the components. Thanks for the insight.

Yes, the reason is that stack references are objects in state, just like everything else. Their names are look-up indices into state, and must be unique. There's no reason you can't have multiple references to the same stack, you just need to use a different name for every one.

so I could do

pulumi.StackReference(name="donkey", stack_name="organization/vpc/dev")
        pulumi.StackReference(name="mule", stack_name="organization/vpc/dev")

Those named stack refs aren't in the examples I can find anywhere but it's in the StackReference class

Re:

Is there a reason why a singleton pattern wouldn't work with python here?

This isn't singleton. You're creating two different objects. The singleton pattern would create only one object, and return it anywhere anyone wanted it.

so I could do

Yeh that code is fine, the two references are to the same stack but they have unique logical names for the deployment engine to track.

here we coalesce non dev stacks to dev stacks so they can use the same vpc, and other stacks will be added here.

Yep, so the problem with that code is that you're configuring it with only the name. You need to configure with the name and stack name separately, as in your previous snippet.

Yeh if you key that StackReference by the current_stack as it's name, then set the name argment to the stack to read I'd think it would then be unique

but if it'll only exist once, due to the singleton, I should be good ? I found in the outputs, when I gave it a name, it would use the name instead of the "organization/vpc/dev".

+   ├─ aws:cloudwatch:LogGroup                       /ec2/authentication/stage/app  create
 +   ├─ aws:iam:Role                                  ec2_instance_profile_role      create
     └─ pulumi:pulumi:StackReference                  donkey                      1 error

but this error was a bit far back in my terminal history so maybe it's not trustworthy

Yes, if it exists only once, you'll be good. I inferred earlier that your pattern needs to be able to create a stack reference in one piece of code but multiple times. If that was the case, you'd either need to pass in a name parameter to that piece of code (and ensure the name is different every time it's called), or use a random name.

alright. I guess it would be nice if pulumi could implement this as a singleton in the back end, so this problem was transparent to users. Really appreciate the help. @echoing-dinner-19531 and @little-cartoon-10569

If they did that, then StackReferences wouldn't be normal Pulumi resources. This solution doesn't work awesomely for your use case, but it does keep the learning curve a little gentler because of the common pattern.