https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
l
You'd have to write the code yourself. You can only import provider-level resources with the providers. It would be feasible to parse the 
import
opt in your _ComponentResource_'s constructor, separate it into the multiple IDs you'd need to import the actual resources that the ComponentResource contains, and import them.
Usually, importing is a once-only thing, so it's usually just easier to import within the ComponentResource's code, targeting just one set of resources at a time. Then remove the import opts.
But if you're likely to be importing things frequently, then writing the code would would be the way to go.
s
got it, thanks!
are you aware of any example code? I’ve seen some docs on import as a resource option but not sure if there’s anything beyond that
l
No, I've never come across that. I suppose the need for repeated imports is not very common...
It does make me thing that I've got a bit of a bug in my code.. theoretically I could accidentally pass 
import
into my component resources, then my could would blindly pass that on to all the nested resources, leading to many failed imports.. I guess I'll rely on code reviews to catch that...
s
I think you’re probably right, my code base is probably a lot more complex than most lol
my component resources are constructed with a bit of metaprogramming, lol
just got time to get back to this and it was pretty easy. i can put the resource id in the stack config when i am ready to import, and have my code check for its existence otherwise just create one
thanks a ton!
👍 1
10 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by