Aqua managed gopls is causing termination of VSCode

[sheldonhull]

aqua version

Please use the latest version.

aqua version 1.32.0 (aacad331354797eed1acbab454f25e4423129f58)

Environment

• macOS
• amd64

Ran into a similar situation with gopls installed via vscode causing termination of VSCode. I installed Go via Brew, and made it the priority on my PATH variable and confirmed the issue was not present when brew installed Go.

Is there a way to opt out of proxy behavior for certain packages to ensure it works and this doesn't happen again?

I did not set any experimental flags either.

Reported Issue: golang/vscode-go#2625

Please let me know what info would be useful for your diagnosing further.

[suzuki-shunsuke]

I guess this issue is related.

• Install go using aqua broke gopls LSP server #710

Is there a way to opt out of proxy behavior for certain packages to ensure it works and this doesn't happen again?

You can change the behavior by setting the environment variable AQUA_EXPERIMENTAL_X_SYS_EXEC.

$ export AQUA_EXPERIMENTAL_X_SYS_EXEC=true

https://aquaproj.github.io/docs/reference/experimental-feature/#aqua_experimental_x_sys_exec

But this flag affects not only specific packages but also all packages.

And this feature has a known issue on macOS.

• aqua freezes when AQUA_EXPERIMENTAL_X_SYS_EXEC is enabled on macOS #729

We haven't investigated this issue for a long time, so I'm not sure the current status of this issue.

[suzuki-shunsuke]

Maybe the following alias works.

alias gopls="$(aqua which gopls)"

aqua which returns an absolute path of the command, so gopls is run directly.
But I'm not sure vscode reads shell configuration such as .bashrc and .zshrc.

Or adding the following script gopls in PATH may work.

#!/usr/bin/env bash

exec "$(aqua which gopls)" "$@"

[suzuki-shunsuke]

And I'm considering enabling AQUA_EXPERIMENTAL_X_SYS_EXEC against only specific tools such as gopls internally.
I have never heard this issue other than gopls, so maybe we can enable AQUA_EXPERIMENTAL_X_SYS_EXEC against only gopls.

AQUA_EXPERIMENTAL_X_SYS_EXEC is disabled by default because there is a known issue, but if we restrict packages maybe we can enable the feature.

[sheldonhull]

Maybe the following alias works.

alias gopls="$(aqua which gopls)"

aqua which returns an absolute path of the command, so gopls is run directly.

But I'm not sure vscode reads shell configuration such as .bashrc and .zshrc.

Or adding the following script gopls in PATH may work.

#!/usr/bin/env bash



exec "$(aqua which gopls)" "$@"

I load VSCode code from the terminal so env vars are honored. I also use direnv so I think that would work. I'll give it a shot and report back when I get a chance.

[sheldonhull]

Any updated recommendation on best practice here? I've had a few crashes with vscode still, but prefer to keep using aqua to install Go.
Without disabling globally any other way I should handle, I'm assuming the snippet or the shell script?

[suzuki-shunsuke]

Did you try this?
#1597 (comment)

[sheldonhull]

Let me look again. I flipped for a while to brew managed go, but really wanted to keep things consistent.

Here's the catch though... might be Go, not just gopls.

[🧱 INT] zsh _ ❯ which -a gopls
/Users/sheldon.hull/go/bin/gopls

I don't have gopls through aqua anymore, just Go.
I think Go + VSCode is having a problem but haven't been able to figure it out yet.

I might try the same approach and use a fully qualified name for Go as well and see if that works.

[suzuki-shunsuke]

Sorry. I guess you have to run not gopls but go directly.

alias go="$(aqua which go)"

#!/usr/bin/env bash

exec "$(aqua which go)" "$@"

And this doesn't work if Go isn't installed yet because aqua which doesn't install the package.
So maybe you have to run go version to ensure go is installed.

#!/usr/bin/env bash

go version > /dev/null 2>&1 # Install Go by lazy install
exec "$(aqua which go)" "$@"

[sheldonhull]

Using the bash script in place on /usr/local/bin/go I haven't had any crashes that I see so far, so using the qualified path is probably important here. Also providing GOROOT to my aqua installed Go on my command line call before invoking goland or code resolve it not figuring out I'm using aqua managed go. This is good progress.

It's a bit clunky so do you have any ideas to solve in aqua itself so folks can easily rely on Aqua for managing their Go installs without any workarounds?

[suzuki-shunsuke]

Thank you for your feedback. Sounds good.

It's a bit clunky so do you have any ideas to solve in aqua itself so folks can easily rely on Aqua for managing their Go installs without any workarounds?

#1597 (comment)

#1597 (comment)

On Linux AQUA_EXPERIMENTAL_X_SYS_EXEC would solve the issue.
I'll take a look if #729 is solved.
And I also consider #1597 (comment)

[sheldonhull]

I'm on macOS, so unfortunately that option isn't viable. I want to make sure it works for both Linux + macOS due to the users I'm helping. Thanks again!

[suzuki-shunsuke]

• Execute commands by execve(2) by default #1925

Released https://github.com/aquaproj/aqua/releases/tag/v2.5.0