pulumi/pulumi-cdk

Support all Pulumi Languages

fitzoh opened this issue ยท 5 comments

Hello!

  • Vote on this issue by adding a ๐Ÿ‘ reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Currently pulumi-cdk only directly supports Typescript:

Note: Currently, the Pulumi CDK Adapter preview is available only for TypeScript/JavaScript users.
(via README)

It would be nice if all Pulumi languages were supported.

This is presumptively made difficult by CDK being based on jsii, which means all of the CDK implementation languages have a ts/js dependency.

Affected area/feature

pulumi-cdk

Thanks @fitzoh for raising an issue to track this.

In prior discussions, we imagined that it may be possible to use JSII itself to project the current library as a multi-language package usable in other CDK languages. We may still need to make the conversion functions for Pulumi Output to/from CDK Token be implemented uniquely for each language, but we believe something along these lines should be able to make this work.

Definitely something we'd love to add.

Out of curiosity - is there a specific Pulumi/CDK language you are looking to use?

Out of curiosity - is there a specific Pulumi/CDK language you are looking to use?

Currently using Python for both CDK and Pulumi

I'm also curious about support for other languages. Are there any plans for this year to support other languages than TS? I'm interested specifically in Python. Being able to use L2/L3 constructs would be a game changer.

Support for other languages will certainly be most welcomed. We have an existing set of CDK stacks written in Python that we're slowly migrating to Pulumi. It would have made a huge difference for us had pulumi-cdk been available for other languages (such as Python).

Looking into this a little I think we should be able to use JSII to do the bulk of the work. JSII will generate an internal JSII node service and a public API in the language SDK. The language SDK will simply proxy to the JSII node service. We would then only have to maintain a handwritten SDK interface in each language which proxies to the JSII node service.