This message was deleted.

You can’t export the resource object, only the properties on it, which is what you’re seeing. You’ll need to run a get on the resource id

get

does call the AWS API right? CDK has both options to construct resource from properties or from lookup. Did I notice correctly that

awsx

may offer the same thing?

get will create a resource for an existing object, which in this case is in another stack. So

.get()

is what you're looking for

awsx

doesn't have any

.get

objects because you'd just use the native aws provider

FWIW 

.get()

 actually adds the resource to your stack state. So then this resource would be tracked in two different stacks? Not sure that’s what you want. 

get[Resource]

 just does a read - which maybe is what you want?

right, so Get somehow looks up another stack, - is there any deeper documentation about Get? It would be nice if I could avoid unnecessary API calls since I already have all data though

This is the

.get()

method which is on each resource. It has nothing to do with “looking up another stack”, it will find the resource and add it to your stack to start tracking it within your pulumi stack (regardless of whether it was originally deployed as part of a pulumi stack or directly in the console or any other way) https://www.pulumi.com/docs/reference/pkg/aws/cloudfront/originaccessidentity/#look-up This is the

get[Resource]

function which is only available for certain resources. It is used to look up information about a resource without adding it to your stack. https://www.pulumi.com/docs/reference/pkg/aws/cloudfront/getdistribution/

Is it possible to create an object 

OriginAccessIdentity

 from this, without calling AWS API with 

OriginAccessIdentity.get()

?

I don’t really understand the premise of your question, why do you need to create the object when you have all of its outputs available to you? What good is the object to you apart from its properties which you already have available in the stackreference?

it will find the resource

- here my question is how and where does it look My point here is that I do not want to pass around a

StackReference

because that's not clear what it is, I want to be able to pass

OriginAccessIdentity

object. And since this particular

StackReference

contains all data about my oai I do not think it is necessary to search or look up.

My point here is that I do not want to pass around a 

StackReference

 because that’s not clear what it is,

I want to be able to pass 

OriginAccessIdentity

 object.

Got it. Unfortunately that would require deserializing your stack reference into an

OriginAccessIdentity

resource but not tracking it as a resource in stack B. We can’t do that at this time. You can do this with the

get[Resource]

functions that are available for some resources, but since this is a bridged terraform provider we do not control which resources have a

get[Resource]

function.

And since this particular 

StackReference

 contains all data about my oai I do not think it is necessary to search or look up.

Right, the benefit of pulumi is that you are just writing code. So if this is something that you want and you believe it is entirely straightforward to do so, you should be able to do so within your code. You could create an

OriginAccessIdentityOutputs

data class and rehydrate it with the properties of your stack reference, or whatever else you need to do to get the end state you would like.

it only requires certain properties of

- this is what I do but I'm balancing on thin ice with this feature. mainly due to comfort

pulumi.export('reource', resource)

vs:

pulumi.export('resource_property', resource.property

in case I need more than 2 properties it becomes too repetitive. but it's pretty much dependent on the resource, so to take a shortcut I simply wanted to expose an entire resource so I do not have to maintain make so many code changes in case I need another property Deserialising

StackReference

into a dataclass is exactly what I'm doing, but

Output

are what makes it difficult (you may remember our previous conversations about it) I wonder if there is a pattern that would allow simple dictionary unpacking on Outputs

I wonder if there is a pattern that would allow simple dictionary unpacking on Outputs

Hmm interesting. So you basically need to have your data class accept an output[dict] and have it resolve the properties to individual outputs. Something like:

class OriginAccessIdentityOutputs:
    def __init__(self, props: Output[dict]) -> None:
        self.prop1 = props.apply(lambda args: args["prop1"])
        self.prop2 = props.apply(lambda args: args["prop2"])

yes, I use pydantic instead of a dataclasses but that would be the very similar:

import pulumi
from pydantic import BaseModel


class OriginAccessIdentity(BaseModel):
    cloudfront_access_identity_path: Union[str, pulumi.Output]
    iam_arn: Union[str, pulumi.Output]

I can instantiate this class like a so:

resource = StackReference.get_output('resource')
OriginAccessIdentity(prop1=resource.apply(lambda x: x['prop1']

but it is possible to instantiate a dataclass or pydantic model from dict

OriginAccessIdentity(**{"prop1":resource.apply(lambda x: x['prop1']}

on top of that pydantic offers

OriginAccessIdentity.parse_obj(dict_with_props)

pain point is repetion of

resource.apply(lambda x: x['prop1']

- which kills the productivity

I feel like we've covered this before: it's not possible to validate the output values outside of an apply because they aren't known at runtime. It would involve completely rearchitecting how Pulumi works. It's never going to be possible. I understand your frustration but what you're asking for isn't the way things work

So, concretely here’s what I recommend: 1. You can open an issue for us to look into this - but honestly it’s unlikely it’ll be prioritized anytime soon. 2. If you know the properties you can do something like:

props = ["prop1", "prop2", "blah"]

OriginAccessIdentityOutputs(**{p: resource.apply(lambda x: x[p]) for p in props})

But honestly is it really worth it?

It goes against the documentation, but I do create resources inside of callback loops in certain circumstances, and that has allowed me to do repetitious things that required an Output to have been applied in order to create further resources… I believe there was an issue raised about this in regards to conditionally creating Resources so they appear in the graph, but maybe not ncessarily creating them in the underlying API… similar to count = 0 in TF.

Thanks Thomas, I read the 4834 while researching this. I know this hack from HCL, however, if felt way less hacky than putting a whole lot of code inside

apply