Is it possible to break up a large `` d...
# general
Is it possible to break up a large
definition into smaller, more manageable py files. For example, I'm specifying multiple AWS SES templates, where I'd like that IAC code to live in its own file. I looked through the docs, but it's not clear on how to achieve in a way similar to how terraform allows modules. A little bit like the example image...
Also, is it possible to rename
and then specify pulumi cli to look for a custom name?
Terrific thanks @billowy-army-68599
@billowy-army-68599 looking through the example the separate pulumi files like are defining classes for the resources defined in which is cool, but I should have been more specific in my question. Is it possible to create and deploy resources in code located outside of For example, if I wanted to create my s3 buckets in, and my lambda functions in
you can define the files, but you’ll always need a
Pulumi won’t just interpolate all files in a directory
Perfect thanks @billowy-army-68599 . Whats the best way to ensure pulumi can see those additional files with their own resournces - some kind of import? Sorry for the questions, I'm coming from a
world where terraform will just automatically see anything with that extension. It's a mental model shift w pulumi, IAC py files and actual application code py files - where they can't be auto-detected.
yes it’s definitely a shit, but Pulumi doesn’t violate the principal of least surprise where terraform just randomly throws what’s in a file at you 😉 You simply define the Component like so: Import it: Then declare the resource:
Ha - valid point... and with some tinkering I managed to figure it out at the same time you were replying. Makes perfect sense now. Defined the resource (an AWS SES template) as a function in a separate
file, exported the
function, imported into
and works like a charm. Thanks for your help 👍
I find ComponentResources are better than exported functions, but both work great!
I'll def spend some more time digging into componentresources. One downside of using python for iac is that people come with their own best practices for applications, not IAC which may actually be a case of unlearning, then learning vs coming fresh to a new IAC language and learning from scratch.
I like what I see so far tho