I'm writing a bunch of code that will go in a pack...
# general
b
I'm writing a bunch of code that will go in a package that can be imported but also needs to be used there and then and i'm having to jump through a lot of hoops with parameters like
Copy code
dnsZone: azure.dns.Zone | (azure.dns.GetZoneResult & azure.dns.GetZoneArgs) | { resourceGroupName: pulumi.Input<string>, name: pulumi.Input<string>, id: pulumi.Input<string> }
i filed an "issue" in september about not being able to access input parameters on the output objects but i wonder if i'm missing something fundamental
seems to me there should be a common type that exists as a super() of GetXArgs, GetXResult, XArgs and XResult
w
@better-rainbow-14549 Not sure I follow exactly - why did you need to write it this way? Which issue was this?
b
in this case, resourceGroup, Name
well say i have a library method installX(dnsZone) {}
and i want to be able to use it e.g.
Copy code
s = new azure.dnszone(); installX(s);
or
Copy code
s = azure.getZone(); installX(s);
w
Ahh - I see. Yes - there is unfortunately no guarantee that
azure.getZone
and
new azure.dnszone()
will return related shapes - and as a general rule it's going to be hard to write code that fully works in that mode. An alternative is to use
azure.dnszone.get()
. This is available on any resource, and reads in an existing resource. The shape it returns is exactly an
azure.dnszone
, so you won't have to convert or use union types. Will this work for your case?
b
oh i didnt realise that even existed
out of interest, how come there's two get?
w
The
.get()
is a Pulumi concept that all resources have by default. The
.getZone
functions are projections of the Terraform "data sources" for Pulumi providers which are built on top of upstream Terraform providers. These are often slightly different, and can be useful in some cases to get indirectly associated properties of resources.
b
awesome i didnt know about these
this changes everything!
thanks
ah it needs the full object id
w
Yes - it is in many cases more limited in what can be used to "lookup" the resource - which is another reason the
getZone
can be useful. If that prevents it from working for your case then you may need to use the
.getZone
. If you do - I'd suggest creating your own interface that has the properties you need - each as a
pulumi.Output<string>
, and then project the results of the two operations into that interface.
We should be able to address https://github.com/pulumi/pulumi-azure/issues/120 soon. cc @stocky-spoon-28903, but this is likely also a relatively pretty simple fix that someone could contribute if interested 😉 .