<@U02E8Q3RN78> - Can this new "Component" approach...
# automation-api
w
@sticky-translator-61903 - Can this new "Component" approach be consumed via the Automation API? In the blog/docs I only saw manual ways to add a package to Pulumi.yaml https://pulumi-community.slack.com/archives/CB36DSVSA/p1743530011640069
t
Could you please clarify the scenario you have in mind? Are you deploying an inline program or an external program? Which language(s)?
w
Inline program using Python. I don't ever have Pulumi.yaml files
t
You can run
pulumi package add
to generate a client SDK for the component and then use it in your inline program.
w
can that be done using the Pulumi Automation API (i.e. within the Python code itself) rather than a CLI command? I'd rather the Python code itself defined the pinned versions of all of the necessary pulumi dependencies
(I know I could use something like
subprocess.Run
from within Python, I was just curious if the Pulumi Automation API has any in-built support)
t
Not that I know of, unfortunately. Do you mind opening an issue?
w
in the main pulumi repo?
t
yep
Although, I'm still not sure how exactly you see it working end-to-end... You need a YourComponent Python SDK generated in order to define resources in your inline programs. You can't generate the SDK this at runtime because then you don't have an SDK to use, right?
w
I guess my main goal is "I'd like to have something I can commit into version control that specifies exactly what version of what packages I'm using" For the main providers
pulumi-aws
pulumi-github
etc., that lives in
pyproject.toml
Is there an equivalent for this new system for Components?
(and I don't want it to be
Pulumi.yaml
, because I don't ever generate one of those)
t
You commit the generated SDK, which contains the component version
w
oh! that was not clear from the blog
so the actual source code files are committed into your project? it's not like an installable library file?
t
So, there are two parts: • Component implementation. For a clear example, let's say it's a TypeScript component in a GitHub repo. • Component client SDK, in your case in Python. It can be generated using
pulumi package add
or using the
packages
section in Pulumi.yaml +
pulumi install
. Both generate some Python files on your disk, inside the
sdks
folder. You use those files to define resources in your program, in your case inside an inline program. You can commit those files with your program.
w
I think I have a pretty good understanding of component implementation. My questions were around Component Client SDK. OK, that makes sense then. I create ephemeral stacks all the time with their name and configuration options (including backend state location) specified all within the Automation API. If I create a Pulumi.yaml file to document what versions of all the Components are being used, it seems like that might interfere with that process...maybe...?
t
You don't have to? Generate it once manually with
pulumi package add
and commit them with your code. Sorry if I am misunderstanding why this is not desireable.
w
I'll play around with it and let you know if it causes problems. I've just never used a Pulumi.yaml file before with my automation API setup, and am unsure if it will interfere with anything or not
t
You don't need a Pulumi.yaml. You need to run
pulumi package add
to generate an SDK. It does not need Pulumi.yaml.