`customRubyCommand` functionality is not portable

[lgarron]

Description

I'm trying to use rv with ruby-lsp: #3861

https://shopify.github.io/ruby-lsp/version-managers.html#custom-activation seems… misguided. For example, trying to do something like PATH=/path/to/ruby/bin:$PATH results in an error for me because I use fish. I'd like to configure .vscode/settings.json inside a repo to set up the correct ruby, and I don't see a way to do this without overly clever workarounds to account for different shell configurations.

Contrast this with https://github.com/rubocop/vscode-rubocop , for which I was able to specify a way to run Ruby that instantly worked:

{
  // …
  "rubocop.commandPath": "./script/ruby-wrapper.ts -S rubocop",
  "rubocop.bundleCommandPath": "./script/ruby-wrapper.ts -S bundle",
}

[lgarron]

I'll also note that:

• I followed the prompts of an error message to set the ruby path to an explicit path (/Users/lgarron/.local/share/rv/rubies/ruby-3.4.6/bin/ruby). This still resulted in failures due to incorrect bundler invocations and incorrect $GEM_PATH usage.
  • I can't seem to find a way to reset this explicit path for the workspace. Resetting the workspace didn't help. Reinstalling the extension didn't help. Is the extension persisting state in a custom way?
  • One of the errors has a link to "Run bundle install". This seems to dump me in a shell and runs bundle install without taking rubyLsp.customRubyCommand into account.

• A lot of the extension commands ("Ruby LSP: Start", "Ruby LSP: Diagnose language server state", "Ruby LSP: Debug the Ruby LSP server") seem to do absolutely no visible effect when I invoke them.

[vinistock]

Thank you for the question.

https://shopify.github.io/ruby-lsp/version-managers.html#custom-activation seems… misguided. For example, trying to do something like PATH=/path/to/ruby/bin:$PATH results in an error for me because I use fish

Note that the documentation mentions before the code block that those are examples. They aren't meant to be an exhaustive list because the goal of the custom activation is exactly to account for less common scenarios or things we don't yet support.

In the case of rv, the custom command needs perform whatever action is required to mutate the environment in the same way that the version manager would in your terminal shell. For example, for chruby that could be chruby 3.3.4 to set all of the environment variables (i.e.: GEM_HOME, RUBY_VERSION, GEM_PATH...) to the correct version. Is there some rv command that can be used to do that?

Also, note that RuboCop doesn't integrate with Bundler to analyze and auto-index your project's dependencies, so it's likely they have looser requirements in terms of your environment. For the Ruby LSP to automatically find where the dependencies are installed, which versions are being used and so on, all RubyGems and Bundler related environment variables must match exactly what happens in your shell. The version manager integrations end up being critical for this to work because all managers mutate some aspect of where or how gems are made available.

[lgarron]

I see.

For the Ruby LSP to automatically find where the dependencies are installed, which versions are being used and so on, all RubyGems and Bundler related environment variables must match exactly what happens in your shell. The version manager integrations end up being critical for this to work because all managers mutate some aspect of where or how gems are made available.

I'm using rv specifically because it doesn't require me to tamper with my shell in any way.

I can run rv shell init fish | source but obviously this cannot be portable configuration for a project.

Here are some alternatives I tried (or would have tried) before filing this issue:

• rv shell init fish, in the hopes that the LSP would try to source the output.
• rv shell init $SHELL | source, except that can't work because $SHELL is a path and is not compatible with other shell.
  • rv shell init (basename $SHELL) | source could work, but this is even less compatible with other shells.

Further, it seems that the LSP assumes that the command can be prepended to another command using &&. fish didn't support this until years after I started using it and and some shells still don't (and never might) ¹, so this seems like a bad assumption to me. Even without that, launching my shell to get env vars from a shell function injected by another tool doesn't feel like something a tool should be doing in 2025?

My only remaining idea to make this work with the current semantics is to nest a shell session inside a ruby invocation, like this:

rv ruby run 3.4.6 -- -C ./src/ruby-gem/ -e "system(\"bash\")

Except:

• I don't know if ruby-lsp would break if you launch a different shell than it thinks it's running. But also I would not feel comfortable launching env["SHELL"].
• I need to get the version from the repository. I'd also like not to be reliant on a global rv binary if possible, i.e. running it from inside the repo. Either of these could be done with a wrapper script, but the extension doesn't have a clear or reliable way to restart the process to debug this.
• I have little confidence the semantics of interacting with the shell would be the same as if it's unwrapped.

Presumably, built-in support for rv would be the most reliable. Barring that, it would be nice to have a way to specify one of the following:

• A custom command to act as ruby that invokes everything else, if possible.² (This is what the name customRubyCommand strongly implies to me, but obviously reappropriating this would be a compatibility issue so it would need a new name.) I'm probably missing something, but it seems to me you can get everything I know of that you need:
  • Getting env vars: customRubyCommand -e 'print(ENV["GEM_HOME"])', customRubyCommand -- -e 'print(ENV["PATH"])' (or even just dump all of ENV)
  • Running a binary: e.g. customRubyCommand -S bundle or use the $PATH from above.
• A command to print env vars for ruby-lsp to use (preferably supporting a format that is easy to serialize safely and correctly, e.g. a JSON object).
• If it's really that hard to avoid invoking the user's shell: a command that prints commands for the shell to source, instead of a command that does the sourcing. This can presumably use much of the same infrastructure, but it avoids the difficult/impossible task of code inside a launched shell in a portable way.

Footnotes

1. https://github.com/nushell/nushell/issues/740 ↩

2. This needs to support a relative path to a script in the repo. ↩