Skip to content

Allow a list of paths to try for the HLS binary, include haskell-language-server by default. #845

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

Closed
michaelpj opened this issue Mar 30, 2023 · 4 comments

Comments

@michaelpj
Copy link
Contributor

There are two main ways you can end up with HLS installed:

  1. You install it from a bindist or similar. This typically means you end up with several HLS binaries plus the wrapper.
  2. Your install it from Hackage or similar. This is more common for Nix users since they tend to have a project-specific setup that includes a specific GHC and HLS.

The problem at the moment is that you have to pick whether the extension will try to launch haskell-language-server-wrapper or haskell-language-server. The most important effect of this is that we can't provide a default config that works for both methods 1 and 2.

Here's a proposal to fix this: make serverExectuablePath into list of strings, try those executables in priority order. Then we can make the default value ["haskell-language-server-wrapper", "haskell-language-server"], which I think would make everyone happy.

@hasufell
Copy link
Member

I'm not sure I understand.

The default is empty:

vscode-haskell/package.json

Lines 140 to 145 in 1438106

"haskell.serverExecutablePath": {
"scope": "machine-overridable",
"type": "string",
"default": "",
"markdownDescription": "Manually set a language server executable. Can be something on the $PATH or the full path to the executable itself. Works with `~,` `${HOME}` and `${workspaceFolder}`."
},

And for good reason. I don't see why a user would want to explicitly set ["haskell-language-server-wrapper", "haskell-language-server"]. There seems to be some other use case that isn't explained here?

@michaelpj
Copy link
Contributor Author

Perhaps I have misunderstood. Do we already look for both haskell-language-server-wrapper and haskell-language-server? I've had people complain that e.g. if they have a shell with just haskell-language-server it doesn't work out of the box and they have to set serverExecutablePath.

@hasufell
Copy link
Member

Do we already look for both haskell-language-server-wrapper and haskell-language-server?

Yes.

/** Searches the PATH. Fails if nothing is found.
*/
async function findHLSinPATH(_context: ExtensionContext, logger: Logger): Promise<string> {
// try PATH
const exes: string[] = ['haskell-language-server-wrapper', 'haskell-language-server'];
logger.info(`Searching for server executables ${exes.join(',')} in $PATH`);
logger.info(`$PATH environment variable: ${process.env.PATH}`);
for (const exe of exes) {
if (executableExists(exe)) {
logger.info(`Found server executable in $PATH: ${exe}`);
return exe;
}
}
throw new MissingToolError('hls');
}

@michaelpj
Copy link
Contributor Author

Alright, looks like I'm out of date!

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

2 participants