Support environment variables for LSPs

[bweston92]

Check for existing issues

• [X] Completed

Describe the feature

(please forgive me if this already exists, I have tried looking)

When spawning a LSP backend for a project, I would like the ability to set an environment variable on the tool.

If applicable, add mockups / screenshots to help present your vision of the feature

Here is an example for what I use in VS Code for their Go extension.

  "go.toolsEnvVars": {
    "GOPACKAGESDRIVER": "${workspaceFolder}/scripts/gopackagesdriver.sh"
  },

Where the script has the following:

exec bazel run -- @io_bazel_rules_go//go/tools/gopackagesdriver "${@}

This fundamentally provides the LSP with code completion artifacts that are generated and not in the working directory.

[mrnugget]

Hey! We already try to load the environment from a project's path when spawning language servers. We do that by starting a shell in that directory, getting its environment, and using that for the language servers.

That means you could fix the issue by using something like direnv to set that env variable in your project directory.

I get the need to set the environment manually, though.

What I'm unclear about: should we merge the two environments? I'd say say so, right?

[bweston92]

Hi @mrnugget thanks for getting back to me.

I've just tired setting .envrc with export GOPACKAGESDRIVER=/Users/.../workspace/.../scripts/gopackagesdriver.sh and restarting Zed.

But no luck and I am not sure how to launch Zed in a way that I'd be able to debug. (maybe I need to restart the LSP separately?)

But in terms of merging the 2 environments, that would be preferred. Overwriting existing variables from the manually entered config.

[mrnugget]

I've just tired setting .envrc with export GOPACKAGESDRIVER=/Users/.../workspace/.../scripts/gopackagesdriver.sh and restarting Zed.

Just to be sure: you also installed direnv and configured it in your shell, right?

But no luck and I am not sure how to launch Zed in a way that I'd be able to debug. (maybe I need to restart the LSP separately?)

Close it completely. Then open it and open that project.

Here's the code for gopls that loads the environment:

https://github.com/zed-industries/zed/blob/a9dbd9a9c04dedd76c7d44250cfdebff673e25ba/crates/languages/src/go.rs#L100-L107

When I open a Go project in a folder with .envrc at the root, this loads that environment and passes it to gopls.

[bweston92]

Sorry I didn't have direnv installed I thought Zed came with it packaged.

It does work this way, but only if I spawn Zed from the terminal but not via the dock.

Do you think we can make this a bit more user friendly?

For me that would mean ability to pass by settings, maybe that isn't the best way to go though, but having to specifically open via terminal to have it functioning correctly doesn't make the best experience.

[mrnugget]

It does work this way, but only if I spawn Zed from the terminal but not via the dock.

It should also work when opened via the doc. When you launch it from the doc and then open your project, what do you get in the log files (zed: open log)?

[bweston92]

I have got both logs here: https://gist.github.com/bweston92/1eafd60bfd188ead5d70e53bfe981b49

[mrnugget]

Ahhh! I see what the issue is! We only use the environment if we find gopls in your PATH in that directory!

You could work around this by adding a gopls in your PATH in your directory, but I think your original issue would be easier to fix if you could just pass environment variables to a given binary and/or if we used the project environment variables when spawning a language server regardless of its location.

Let me think about that.