[verdverm]

If I use Python for my Pulumi, how could I reuse the work of a peer who uses JS for Pulumi?

Do we need to have multiple "mirrors" of our internal infra modules? Or do we need multiple language runtimes in our deployment runner in CI?

With TF, there is one language and one binary

[jaxxstorm]

You build a multi language component: https://www.pulumi.com/blog/pulumiup-pulumi-packages-multi-l...

You can then publish a language SDK for your supported languages, so npm for node packages, pip for python.

The invoking peer needs to have the language they're using runtime locally

The python boilerplater is here: https://github.com/pulumi/pulumi-component-provider-py-boile...

Here's an example component built in Go: https://github.com/jaxxstorm/pulumi-productionapp

Then in examples you can see it being using: https://github.com/jaxxstorm/pulumi-productionapp/tree/main/...

[verdverm]

Thanks for that blog link! I have been asking this question for a while and you are the first to provide an actual useful answer.

Can I pass arguments to these components in other languages? Still unclear

It looks to limit, or create specific points, of where the reuse can happen. Like it is still impossible to use a helper function from one runtime in another. So we still need to maintain utilities in multiple languages

Either way, it looks like a lot more complexity for anyone who goes down this path

[dmattia]

You would have separate JS and Python stacks that could share outputs, similar to a `terraform_remote_state` data source in terraform-land. There's also a yaml "language" support if you just want to use a config language: https://www.pulumi.com/docs/intro/languages/yaml/, but I have never messed with this, as we really just use typescript.

As somebody who maintains public terraform providers though, I do want to point out that "With TF, there is one language and one binary" is not totally accurate. Each provider you install must be installed separately, and runs separately as its own process, and the core terraform library calls out to the providers via gRPC. You can verify this by running `ps` during your next terraform run and seeing all the different providers on their own processes.

Pulumi actually uses the same gRPC setup, and can even communicate with Terraform providers. So the only real different part binary wise is the "core" terraform binary being replaced by a different "core" pulumi binary based on the language you are using, but the rest of the providers will all be the same, and you'll run multiple languages either way.

If your company only supports one or a few languages in your normal production code, you can also just use those languages for Pulumi, and still get one language and one binary. There's nothing forcing you to use multiple different languages.

[verdverm]

It's still an extra dimension of complexity to support N language runtimes. Won't each of them still need the same TF providers?

With TF, sure there is a call to fetch those providers & modules, but still, I don't have to install N language runtimes, which needs its own IaC to build, thus adding another process to the mix

I would assume most eng orgs try to limit their Pulumi to one language to skirt this issue

[re-thc]

> If I use Python for my Pulumi, how could I reuse the work of a peer who uses JS for Pulumi?

Standardize on the language(s). It's important. Pick 1 for Pulumi and standardize on it. Even better pick 1 or 2 for the whole company and standardize on it. In a large company...

> Or do we need multiple language runtimes in our deployment runner in CI?

Already does happen.

But back to the origin question: you can create Pulumi packages that can generate usage in different languages as required.