Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept GOROOT configuration #42

Open
object88 opened this issue Feb 28, 2018 · 5 comments
Open

Accept GOROOT configuration #42

object88 opened this issue Feb 28, 2018 · 5 comments

Comments

@object88
Copy link
Owner

The InitializationParams provided to the initialize JSONRPC2 method may include a custom GOROOT location, as specified by an editor. If so, override the runtime specified location in the loader.

@object88
Copy link
Owner Author

object88 commented Mar 2, 2018

The goroot is not provided in the initialize method (unless we can find a way to shoe-horn it in). We do get a didChangeConfiguration notification, which includes the data, but it's not clear that this will be common among all clients. Starting with v3.6 of the LSP spec, there will be a configuration request from the server to the client. With that, we can request exact configuration information from the client as soon as we get the initialized notification. When the client responds, we can determine any goroot override.

Unfortunately 3.6 isn't implemented in the vscode-languageserver project yet, which we depend on.

@object88
Copy link
Owner Author

object88 commented Mar 2, 2018

@object88
Copy link
Owner Author

object88 commented Mar 6, 2018

The NPM packages with new versions have been released.

@object88
Copy link
Owner Author

Paused again. We are running into a problem where we can't get the GOROOT information fast enough. After the Handler is created, we start processing the request queue. This is first routed through the uninitedHandler method, but once we finish with Initialize, we switch over. This is in hopes of processing a didChangeConfiguration or configuration request, but we are quickly getting an openFile request, and this fails, which is just symptomatic of the greater problem -- unless we are OK with processing requests out-of-order (which is discouraged but not disallowed, esp. if there isn't a way to ensure that interdependent requests aren't processed OOO).

Instead, we are going to try to manage this by first preloading the default GOROOT when the server starts. All workspaces, when they are first opened, will be evaluated against that environment. If later a configuration changed notification comes in which points to a different GOROOT, we will need to make sure that it's loaded, and then reload the workspace. In this way, we should also be able to change GOROOTs (and other configuration) on the fly without stopping the app or closing the workspace.

@object88
Copy link
Owner Author

Dependent on work started in #54 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant