No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

&gt; • How do we call it in our stacks? The method is async.
Ah :face_palm:
I'll raise an issue about that, all the other SDKs support async calls in the program but I don't think we have a great way to do this in python yet (short of the user nesting the whole program in an asyncio.run call)

&gt; How come our code needs to care if an output is secret or not?
Because you may want to change behaviour based on it being secret or not, more importantly we didn't want people to inadvertently leak secret values because they just didn't think about that the values could be secrets.

<https://github.com/pulumi/pulumi/issues/12172>

It's rare I see actual code referencing config/stackreferences directly; aliasing them to globals or a config namespace instead.

Them being Stackreferences complicates it, too, as Stack B now needs to know whether Stack A is exporting a secret. The Stacks may not be part of the same package, or codebase, meaning co-ordinated updates are needed.

I see this becoming common practice:

```# config.py
def get_output_details(stack, name):
  from pulumi.runtime.sync_await import _sync_await
  d = _sync_await(
    stack.get_output_details(name)
  )
  return d.value if d.value is not None else d.secret_value```

Yes, I suspect your right there. It's tricky trying to build something "just does the right thing" and "is easy to use".
People want "plain" values, just str or int so they can work with them easier. But they also want secrets correctly tracked so they don't get leaked, but plain values can't track that.

It's a tough one, yeah.
Heard a few people say they use (or consider using) Pulumi purely for the Secrets support

regarding async; Jupyter (bits anyway) is moving toward being async-first, and wrapping sync functions up. <https://github.com/jupyter/nbclient/blob/7a7b1dcbdeab2e1d6f644cf8eced5478134e2afc/nbclient/client.py#L508-L536|example>.

Could be a nice pattern to adopt for the public API:
```def async_get_output_details(self, ...): ...
get_output_details = run_sync(async_get_output_details)```