reproducibility issue with solidlsp bash-language-server and shellcheck

[alaestor]

Disclaimer: agent hit a bump and alerted me to a small problem.

Haven't looked too closely so I'm making this a discussion rather than opening an issue: there may be some configuration option that jumps over this path, but I didn't see one at a glance.

solidlsp appears to try and install bash-language-server and shellcheck even if they already exist on the system and are exposed in PATH. This complicates reproducibility and offline usage.

The agent fixed it for my usecase by applying a patch and repacking serena in a closure with the expected tooling.

If this is a mistake and there's a known workaround, please let me know because I wasn't able to find it by briefly searching issues/PR/disucssions.

If it is a problem, then it may likely effect other LSPs. A quick slop-audit:

• Yes. The same pattern appears widely.

  Clear single-executable candidates

  - ansible-language-server
  - intelephense
  - vscode-json-languageserver
  - some-sass-language-server
  - vscode-html-language-server
  - yaml-language-server
  - vtsls
  - marksman
  - texlab
  - terraform-ls
  - clojure-lsp
  - cue
  - dart
  - fsautocomplete

  These currently install/download managed copies without first checking PATH.

  More complicated candidates

  - TypeScript, Angular, Vue, and Svelte require coordinated TypeScript SDK/plugin paths.
  - Solidity also manages Forge.
  - Groovy, Kotlin, Java, C#, and PowerShell manage runtimes or multi-file distributions.
  - Ada and Kotlin already support explicit ls_path configuration, making PATH lookup less urgent.

  Already following the desired pattern

  Examples include clangd, rust-analyzer, nixd, lua-language-server, taplo, luau-lsp, ccls, Haxe,
  Elm, Scala/Metals, Ruby LSP, and several others.

[opcode81]

there may be some configuration option that jumps over this path

There is: https://oraios.github.io/serena/02-usage/050_configuration.html#customizing-the-language-server-launch-command
If you set ls_path for the bash language server in your global configuration, you can use any fixed version of the server you want.

This complicates reproducibility

From Serena's perspective, it is the exact opposite.
Only by using a fixed version of every language server can we ensure that the integration with Serena is tested, producing reproducible behaviour for users.

[alaestor]

Thank you!

It seems the problem is more narrowly scoped than I originally thought. I can direct the bash-lsp command to my supplied program, but serena seems to override SHELLCHECK_PATH to always point at its managed version; unless I'm missing something else again?

I'm able to work around this by just wrapping my bash-lsp to override the environment variable (much better than the invasive patch approach...)