This message was deleted.

So are you asking for full control of the internal language host to be exposed? Cause I don't see the pulumi team going for that personally, since the language host is an implementation detail of the Automation API and "shouldn't" touch their public API

Basically, when I first saw how the language server worked my initial thought was it didn't need to be a completely separate generic host, since I was already building that with preferred settings, so having it integrate better with an existing generic host would be preferable - the same way other dotnet libraries provide extensions to the host, or maybe even integrate as a background service? The logging issue referenced is an example of something that could subsequently be configured as preferred rather than ending up with a mix of logging formatters and sinks etc.

If it were an extension that added the necessary gRPC service to an existing API, than we would need to deal with this gRPC functionality now being exposed on your API, so that would be tough I think. We'd need to either make it internal only or figure out a way to authenticate it, both of which are solved by it being a separate internal host An additional difficulty is we are passing in a reference to the pulumi program that should be used via

PulumiFn

. The current architecture is kind of relying on the fact that the pulumi program to language host is 1:1 - if it was a long lived language host, than we would need additional services to handle passing in the pulumi program to the language host and we would need to figure out a way for the language host to select the appropriate pulumi program Ultimately I think attaching it to an existing web host is kind of antithetical to the current architecture, and may be wasted effort since the future goals are to remove the Automation API's CLI-dependency which would mean the web host we are spinning up may no longer be necessary when that happens anyways

These were just my initial thoughts, so your thoughts and feedback are very illuminating, thanks! I guess my initial concern is that I'd want to have some control of the logging in particular, to unify its formatting and sinks, but maybe that's moot if the logging is completely silenced for this internal host? Of course it would be awesome if this host was no longer needed if/when the cli interop is removed! FWIW. I'm initially using a generic host with a console/cli application, not a web application.

Gotcha. Yea I have considered some conditional logging or controlled logging of the internal language host but you may also be right that it may be moot if the intention is for the language host to be silent

Looking forward to the silence after the merge... 😀