Hey there, I’m very interested in Pulumi Packages, and especially the ability to work across languages:

With Pulumi Packages, Resources and Components can be written once, in your preferred language, and made available in all the other languages supported by Pulumi.

Is there any documentation or examples of Pulumi Native Provider Packages being written in something other than Go ? There’s this repo template: https://github.com/pulumi/pulumi-provider-boilerplate But it’s not very clear to me which parts of this are Go-specific and which aren’t. The

schema.json

is definitely a central piece, but how do you link what you declare in the schema to your code ? Is it even possible to build a Native Package in e.g. Python with Pulumi right now ?

Providers are currently written only in Go. Multi-language authoring applies to components.

I see. Thanks Mikhail 🙂 Is it in the roadmap though ? Multi-language authoring ?

To further clarify, native providers are currently only written in go. There are no plans to extend this into other languages currently. The multi-language component providers can, however, be authored in any language.

I see, thanks Komal The marketing you’re using at Pulumi is a bit deceptive though : to a CTO (like me), it sounds like you’re saying “You can integrate any resource you like in any language you like” That’s not entirely true though : I mean there are Dynamic Providers but there are definitely flaws to this system and inconsistencies with the Native Providers Dynamic Providers aren’t currently meant to build “real” providers (e.g. a

pulumi-slack

or something like that), are they ?

This is a fair point cc @flaky-ghost-73674

Thanks for the feedback here. After discussing more internally, it is technically possible, but not at all enjoyable or documented or recommended, to author native providers in other languages. As Komal mentioned, we don’t currently have plans on the roadmap to make this easier. (To my knowledge, you may be the first person that’s expressed interest in doing so, though I suspect we’ll hear from more as we release more first-party native providers.) But, I think the conversation is a good one - we need to do a better job of articulating when to use native providers vs. dynamic providers, and I think we need to consider making a good experience for authoring native providers outside of Go. I will take this feedback back to the team.