i get this warning ``` Diagnostics: pulumi:pulum...
# python
i get this warning
Copy code
  pulumi:pulumi:Stack (project-factory-prod):
    <coroutine object get_project at 0x7f761ffaf448>

    ./__main__.py:61: RuntimeWarning: coroutine 'get_project' was never awaited
    RuntimeWarning: Enable tracemalloc to get the object allocation traceback
I am 100% not a python expert, but I believe that the problem here is that get_project actually returns a future instead of a prompt value, and if you don't wait for it, you'll never see the underlying value and get this error. How are you using the
that you defined?
yeah, currently all
stuff is async based (coroutines)
(there's discussion on github to change this because it's a pain in the butt and doesn't really provide much)
so you should probably
Copy code
async def get_project(self):
        return await gcp.organizations.get_project(project_id=self.project_name)
Now, the weird thing is that this should still work, assuming the return value got handed to pulumi
or, if you tried to use it, it should have given type-related errors
I tried that too ..making it a async function , but when calling that function from somewhere using asyncio.run(self.get_project()) gives a eventloop error
Even if i try to get the same eventloop used pulumi and add this task part of that loop
Copy code
loop = asyncio.get_running_loop()
proj_exist = loop.create_task(self.get_project())
this task is created as a future task , but basically what i want to do is if project_exist , skip some task ..
Also what is the proper way suggested to do some check , like
Copy code
if proj_exist:
`stop pulumi run`
well, you're supposed to use it like an Input, so if you give a resource an awaitable (directly or burried), pulumi will resolve it
you just need to wrap it in a task because pulumi attempts to await stuff more than once internally
FWIW, we are going to be landing changes over the next few days to make these
methods complete synchronously: https://github.com/pulumi/pulumi/pull/3019 is the core work in our runtime to support this and we'll be pushing changes out to our providers over the next few days to consume this. Once this is complete, these calls should behave like you'd like.
👍 1
because inner event loops are fun!