Is there any news whether or not we may expect a J...
# automation-api
l
Is there any news whether or not we may expect a Java version of the Automation API? So I'm not asking for full language support to write infra code in Java (https://github.com/pulumi/pulumi/issues/1539), only the Automation API.
b
That's an interesting thought. So it would be like a partial implementation of Automation API then, because it would only be able to do local programs?
b
I don't believe we have a roadmap item for this at the moment šŸ˜ž
l
@bored-oyster-3147 given the Automation API still calls the pulumi CLI, can you elaborate on your statement
only be able to do local programs
? What is meant with
local
in this case?
b
Automation API has currently defined 3 different kinds of pulumi programs: ā€¢ local: when you point Automation API at a directory that contains an existing pulumi project ā€¢ inline: when you give Automation API infrastructure code directly (and your infrastructure code is executed in-process) ā€¢ remote: when you point Automation API at a remote repository containing an existing pulumi project So if you implemented Automation API in Java such a way that you couldn't write infrastructure code in Java, you would not be able to do
inline
programs.
l
@bored-oyster-3147 clear. For my use case, I do not have a need for
inline
programs, which means I could live with this limitation. Adding to this, we will mainly have the
local
setup.
b
I don't do Java really but I don't think this would be very difficult. Most of the Automation API complexity comes from supporting
inline
programs. A partial Automation API implementation for Java would only need the parts that call out to the CLI
f
As @billowy-army-68599 mentioned, Java support is not currently on the roadmap. Would you be willing to file an issue in https://github.com/pulumi/pulumi/issues so other folks can upvote?
b
@flaky-ghost-73674 we do have an issue for it https://github.com/pulumi/pulumi/issues/1539
f
Ah, that one is for general Java support. The Automation API distinction is a good one, and worth a separate issue IMO.
šŸ’Æ 1
b
-šŸ‘
l
This is something I've thought about. Altering the approach of automation API to rely on gRPC to make it easier to roll out support for non-core languages: https://github.com/pulumi/pulumi/issues/7220
Dependent on some rewrites to enable a "single binary automation api" where we link directly into the pulumi engine rather than relying on the CLI: https://github.com/pulumi/pulumi/issues/7219
If we did this we'd get Java, C++, PHP, and Ruby support for automation api "for free" https://grpc.io/docs/languages/
šŸš€ 3