bazel binary detection (in VSC with bazel-vscode-java) does not find custom script on PATH which runs bazelisk instead of bazel

[vorburger]

@guw me again - sorry! 😈 (Hope this continous intended to be constructive feedback is a useful project contribution...)

In enola-dev/enola#354 I'm exploring supporting (testing & documenting) GitHub Codespaces for https://docs.enola.dev/dev/ide/#visual-studio-code-vsc. (That's with https://github.com/salesforce/bazel-vscode-java, but based on my current understanding of what's what here, the change / fix required will probably be in code in this repo, so I'm filing this here; let me know if you prefer it on the other project.)

I've run into the following errors:

WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
Dec 09, 2023 11:17:22 AM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic
Dec 09, 2023 11:17:22 AM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic
[Error - 11:17:27 AM] Dec 9, 2023, 11:17:27 AM Unable to detect Bazel version of binary 'bazel'!
Cannot run program "bazel": error=2, No such file or directory
java.io.IOException: Cannot run program "bazel": error=2, No such file or directory
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
	at com.salesforce.bazel.sdk.command.BazelBinaryVersionDetector.detectVersion(BazelBinaryVersionDetector.java:57)
	at com.salesforce.bazel.eclipse.core.extensions.DetectBazelVersionAndSetBinaryJob.run(DetectBazelVersionAndSetBinaryJob.java:52)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.io.IOException: error=2, No such file or directory
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:244)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
	... 4 more

[Error - 11:17:27 AM] Dec 9, 2023, 11:17:27 AM Opening element at '/workspaces/enola' failed with: 'bazel info failed in workspace '/workspaces/enola': Cannot run program "bazel" (in directory "/workspaces/enola"): error=2, No such file or directory
Please check the bazel output and binary setup/configuration!'
bazel info failed in workspace '/workspaces/enola': Cannot run program "bazel" (in directory "/workspaces/enola"): error=2, No such file or directory
Please check the bazel output and binary setup/configuration!
org.eclipse.core.runtime.CoreException: bazel info failed in workspace '/workspaces/enola': Cannot run program "bazel" (in directory "/workspaces/enola"): error=2, No such file or directory
Please check the bazel output and binary setup/configuration!
	at com.salesforce.bazel.eclipse.core.model.BazelWorkspaceInfo.load(BazelWorkspaceInfo.java:350)
	at com.salesforce.bazel.eclipse.core.model.BazelWorkspace.createInfo(BazelWorkspace.java:165)
	at com.salesforce.bazel.eclipse.core.model.BazelWorkspace.createInfo(BazelWorkspace.java:1)
	at com.salesforce.bazel.eclipse.core.model.BazelElementOpenJob.run(BazelElementOpenJob.java:110)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.io.IOException: Cannot run program "bazel" (in directory "/workspaces/enola"): error=2, No such file or directory
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
	at com.salesforce.bazel.sdk.command.DefaultBazelCommandExecutor.doExecuteProcess(DefaultBazelCommandExecutor.java:144)
	at com.salesforce.bazel.sdk.command.DefaultBazelCommandExecutor.execute(DefaultBazelCommandExecutor.java:219)
	at com.salesforce.bazel.eclipse.core.extensions.ExtensibleCommandExecutor.execute(ExtensibleCommandExecutor.java:44)
	at com.salesforce.bazel.eclipse.core.model.execution.BazelReadOnlyJob.run(BazelReadOnlyJob.java:54)
	... 1 more
Caused by: java.io.IOException: error=2, No such file or directory
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:314)
	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:244)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
	... 6 more

So it's failing to find bazel to exec it, in two places, the DefaultBazelCommandExecutor as well as the BazelBinaryVersionDetector (which, according to this stack trace, does not use the former).

This is because I don't actually directly have a bazel binary on my PATH - intentionally. Instead, I use bazelisk https://github.com/bazelbuild/bazelisk - only.

On my local (Fedora-based) workstation, in VSC, where it works great. This is because I have a https://github.com/vorburger/vorburger-dotfiles-bin-etc/blob/main/bin/bazel (and also a https://github.com/vorburger/vorburger-dotfiles-bin-etc/blob/main/dotfiles/fish/completions/bazel.fish, but that's not really relevant, here).

For some reason which I haven't fully understood yet, on a GitHub Codespace, that doesn't seem to work (whereas it does locally, for me).

I'm also vaguely aware that there Linux Kernel configuration/s related to direct support, or not, of "Hashbang" scripts for exec; no clue if that could be related, here.

I haven't had a closer look at your related code here yet. It may have something to do with PATH, and if you launch with that bash -c trick (you know what I mean?) or directly exec. BTW https://github.com/vorburger/ch.vorburger.exec is a little launcher library of mine, where I had been meaning to add support (abstraction) for this kind of thing for a while.

Actually the PATH may well be the culprit? Here are some details from my Codespace Terminal - but the process context in which the LSP server runs may be different, of course - so my "custom" ~/bin/ is probably not on the PATH there?

I can try to dig a little bit deeper some other time than right now, but I thought I would already file this here, if you have an initial reaction.

I guess another option than "fixing" this whole PATH could be to allow configuring what binary to use, and let users set bazelisk instead of bazel? Or even auto-detect / try both, that could be neat. Or just add support to emulate https://ij.bazel.build/docs/project-views.html#bazel_binary, maybe?

[vorburger]

Here are some details from my Codespace Terminal

…/enola on  codespaces +12 -12 [!] via 🐍 ❯ bazel --version
bazel 6.1.2

…/enola on  codespaces +12 -12 [!] via 🐍 ❯ which bazel
/workspaces/.codespaces/.persistedshare/dotfiles/bin/bazel

…/enola on  codespaces +12 -12 [!] via 🐍 ❯ cat (which bazel)
# bazel is also defined as alias for interactive shell (which is better for auto-completion) - this script is for tools who need to find bazel on the PATH (such as georgewfraser/java-language-server for VSC).
# NB Must use "$@" and not "$*", see https://github.com/georgewfraser/java-language-server/issues/238.

bazelisk "$@"

…/enola on  codespaces +12 -12 [!] via 🐍 ❯ echo $PATH
/workspaces/.codespaces/.persistedshare/dotfiles/bin /home/codespace/.local/bin /go/bin /home/codespace/.fzf/bin /usr/local/rvm/gems/ruby-3.2.2/bin /usr/local/rvm/gems/ruby-3.2.2@global/bin /usr/local/rvm/rubies/ruby-3.2.2/bin /vscode/bin/linux-x64/02b90714767f05c734ac29a64d0e5b4768f532d8-insider/bin/remote-cli /home/codespace/.dotnet /home/codespace/nvm/current/bin /home/codespace/.php/current/bin /home/codespace/.python/current/bin /home/codespace/java/current/bin /home/codespace/.ruby/current/bin /home/codespace/.local/bin /usr/local/python/current/bin /usr/local/py-utils/bin /usr/local/oryx /usr/local/go/bin /usr/local/sdkman/bin /usr/local/sdkman/candidates/java/current/bin /usr/local/sdkman/candidates/gradle/current/bin /usr/local/sdkman/candidates/maven/current/bin /usr/local/sdkman/candidates/ant/current/bin /usr/local/rvm/gems/default/bin /usr/local/rvm/gems/default@global/bin /usr/local/rvm/rubies/default/bin /usr/local/share/rbenv/bin /usr/local/php/current/bin /opt/conda/bin /usr/local/nvs /usr/local/share/nvm/versions/node/v20.9.0/bin /usr/local/hugo/bin /usr/local/dotnet/current /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/local/rvm/bin

[vorburger]

(...) a closer look at your related code here

Starting to stare at https://github.com/salesforce/bazel-eclipse/blob/dceb31d92b9f448d2e63add6f21e693326fdcd07/bundles/com.salesforce.bazel.sdk/src/com/salesforce/bazel/sdk/command/BazelBinaryVersionDetector.java, I stumble over 1fed8ec where you seem to have already added support for https://ij.bazel.build/docs/project-views.html#bazel_binary - let me try that!

[guw]

Yes, bazel_binary should work.

But there is a gap in detecting the default binary, which might still cause errors in the log.

We use the bash -c workaround only on MacOS because there VS Code and/or Eclipse is usually launched from the desktop as GUI app. On MacOS GUI apps don't inherit the shell environment.

In general, we don't scan but expect bazel do be in PATH. I recommend Bazelisk because it allows switching versions more easily. On MacOS, Homebrew sets up a symlink from bazel to bazelisk binary into the PATH.

I suspect that the VS Code server process running in Codespaces does not inherit your user environment. Thus, it does not have the bazel binary. I wonder if you need to somehow make it part of the devcontainer.json?

[vorburger]

I've added bazel_binary: bazelisk to https://github.com/enola-dev/enola/blob/main/.bazelproject, and ran Java: Restart Language Server and then Bazel: Refresh Bazel Build Targets but that now says Failed to find a Bazel workspace... I'll further investigate that later.

We use the bash -c workaround only on MacOS (...) sets up a symlink from bazel to bazelisk binary into the PATH.

I'll try to replace my https://github.com/vorburger/vorburger-dotfiles-bin-etc/blob/main/bin/bazel with a ln -s, that's probably better/easier.

I wonder if you need to somehow make it part of the devcontainer.json?

I was hoping to avoid needing to deal with Dev Container set-up, but yeah, I'll look more into that.

Let me close this for now, as that bazel VS bazelisk issue seems solved. I'll investigate further in enola-dev/enola#354, and more specific issues, if required.