https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# getting-started
s
This message was deleted.
e
👍 1
h
Nice! That's a good starting point. Thank you!
Not directed "you", I see it as a general pattern: I find it interesting that "_ as Code" seems to always require a local tool rather than only a library. cdk, pulumi, ... all require the commands to be present. Is there a specific reason everyone chooses this? Why would it be "worse" to just expect someone to instantiate a sort of config (or provide options) and just run the code... • 
go run main.go [my-personal-flags]
• 
python main.py [my-personal-flags]
Really curious as to why this seems to be preferred by "everyone"
e
In my experience (having built a couple of tools like this) it's a few reasons: 1. Handling argument parsing correctly rather than trusting the user will pass argv down to the tool. Even more fun if you expect the run api to be well typed and not just take a string[]. 2. Having a consistent "start point". Everything you do with pulumi is started from the pulumi command, rather than like stack configuration being done via 
pulumi
but running your actual program being done via 
go run
3. Ensuring that the right pulumi binary is used. Even if we supported something like 
go run
it would somewhere internally have to shell out to the 
pulumi
binary, we can't write an actual native library for all of pulumi in every language. I think the main point is two. Just having that consistent start point for everything. We do have an issue around supporting this "just go run" it approach https://github.com/pulumi/pulumi/issues/5538 but it hasn't had a lot of traction.
Open in Slack
PreviousNext
Powered by