<@U01E602D5JA> starting a slack thread following o...
# dotnet
@bored-oyster-3147 starting a slack thread following on from https://github.com/pulumi/pulumi/pull/7023#issuecomment-839082652 ...
I'm using my own generic host with the dotnet automation api, wiring up the usual config, logging, dependency injection etc, and was wondering / hoping this language server could be integrated better with such a generic host so that I have full control of the previous concerns. Thoughts?
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
But if there is some specific problem you're trying to solve with your use-case, we could try to figure it out
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.
I'll try to put a public project up on GitHub capturing the essence of what I'm playing with
I think other issues that have been logged could also be avoided by separating the host from extensions to the host
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
. 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
Also just a separate thought, Automation API library as it stands is obviously not exclusive to Web APIs. So if such an extension or feature were to exist it likely wouldn't touch or be part of the same library, it would be something like
. I personally don't really see this happening, because like I said the language host is an implementation detail and bringing any of that or too much of that into the Public API would tie them to it. Could tag some pulumi folks here to get their input
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... 😀
😅 1