https://pulumi.com
Join Slack
Menu
Home
Archive
This message was deleted.
# general
s
This message was deleted.
l
The support for core Pulumi features is the same across all languages. Some features provided through additional libraries (e.g. policies, AWSX) are available in some languages and not others.
đź‘Ť 1
Not sure re: multi-language components. It's a fairly new feature and I haven't used it myself.
b
I think dynamic providers are only available in js and python. https://www.pulumi.com/blog/dynamic-providers/
b
@brash-airline-37413 dynamic providers are the one mechanism that is worth considering with cross language support. With regards to multi language components, my personal preferences is to use Go because they don't require a language runtime to interpret the program on the user side. What that means is, you don't need node/python on the user's machine when invoking. Go multi language components just need you to distribute the binary they create You can work around that using something like `nexe`: https://github.com/nexe/nexe but I haven't tried it myself yet
b
Actually I did have a play around with the typescript template repository and it does use nexe however it still wouldn’t allow somebody to write a component in python and another person to write one in typescript without having multiple packages.
@billowy-army-68599 I thought dynamic providers were more for integrating with new clouds etc have I misunderstood that?
b
however it still wouldn’t allow somebody to write a component in python and another person to write one in typescript without having multiple packages.
can you elaborate a little more here?
dynamic providers have lots of uses cases, for example doing OS provisioning tasks is another one, but unimplemented cloud resources is a common use case for them
b
so effectively we have 4 teams and they can’t agree on what languages to write the components for the organisation in. Would dynamic providers allow some teams to contribute componentresources as python and another as typescript?
(context is for a cloud accelerator so componentresources which are reusable across the org and compliant with the orgs security policies etc)
b
no, dynamic providers are just implementation mechanisms in each language
multi language components would allow the teams in questions to write the components in the languagr they choose and let them share user SDKs across all four supported languages
so they wouldn't really have to "choose" because Team A could write their components in typescript and team B would be able to consume them in python, and write their own componets in python
the ownership model would probably be the thing that dictates that
b
ok but since it’s a cloud accelerator we actually want to author the original ComponentResources in multiple languages is that possible currently?
so someone could add a componentresource in python and another team could add one in typescript and then it cross compiles them into the remaining
(sorry i know its a wierd question, it’s just easier to solve this at a tech level than at a human level due to ingrained beliefs between different developers when it comes to programming languages)
b
yes that's totally possible, as long as they are different components. I'd love to get on a call and chat about this if that helps? some time this week perhaps?
2 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by