bundle: "Could not find command" error

[mislav]

Description

Ruby LSP Information

VS Code Version

1.95.3

Ruby LSP Extension Version

0.8.13

Ruby LSP Server Version

Unknown

Ruby LSP Addons

Ruby Version

3.0.7

Ruby Version Manager

none

Installed Extensions

Click to expand

• copy-github-url (0.14.0)
• debugpy (2024.12.0)
• go (0.42.1)
• prettier-vscode (11.0.0)
• python (2024.20.0)
• rewrap (1.16.3)
• ruby-lsp (0.8.13)
• shellcheck (0.37.1)
• vscode-pylance (2024.11.2)

Ruby LSP Settings

Click to expand

Workspace

{
  "rubyVersionManager": {
    "identifier": "none"
  }
}

User

{
  "enableExperimentalFeatures": false,
  "enabledFeatures": {
    "codeActions": true,
    "diagnostics": true,
    "documentHighlights": true,
    "documentLink": true,
    "documentSymbols": true,
    "foldingRanges": true,
    "formatting": true,
    "hover": true,
    "inlayHint": true,
    "onTypeFormatting": true,
    "selectionRanges": true,
    "semanticHighlighting": true,
    "completion": true,
    "codeLens": true,
    "definition": true,
    "workspaceSymbol": true,
    "signatureHelp": true,
    "typeHierarchy": true
  },
  "featuresConfiguration": {},
  "addonSettings": {},
  "rubyVersionManager": {
    "identifier": "none"
  },
  "customRubyCommand": "",
  "formatter": "auto",
  "linters": null,
  "bundleGemfile": "",
  "testTimeout": 30,
  "branch": "",
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "",
  "indexing": {},
  "erbSupport": true,
  "useLauncher": false,
  "featureFlags": {}
}

Reproduction steps

1. BUNDLE_BIN=path/to/binstubs bundle binstub --all
2. Prepend path/to/binstubs to PATH
3. Load the project in VS Code
4. See error when starting Ruby LSP

Ruby LSP> Command: (bundle _2.2.33_ check || bundle _2.2.33_ install) 1>&2

<TIMESTAMP> [info] (<PROJECT>) Could not find command "_2.2.33_".

I suspect this is because the <command> _<version>_ invocation syntax might be supported by binstubs generated by Rubygems, but is not supported by binstubs generated by Bundler. Furthermore, it's entirely unnecessary to explicitly specify a Bundler version: first of all, this version likely comes from a Gemfile.lock, and Bundler already has a mechanism to activate the right bundler version according to the lockfile. Second, the Ruby LSP extension also seems to set the BUNDLER_VERSION environment variable before invoking bundle (which I also think is unnecessary):

ruby-lsp/lib/ruby_lsp/setup_bundler.rb

Lines 399 to 405 in 9e24cff

	if @bundler_version
	env["BUNDLER_VERSION"] = @bundler_version.to_s
	install_bundler_if_needed
	return "bundle _#{@bundler_version}_"
	end
	"bundle"

[vinistock]

Thank you for the report! We added those as part of fixing #2532.

To compose the Ruby LSP bundle, we start by executing the gem without bundle exec, which means the version of Bundler we require during this setup step may not match what is in the lockfile. Then after our setup is complete, we re-launch with bundle exec and a mutate environment with all of the Bundler variables adjusted to point to the right place.

The issue was that if the version of Bundler we had required during setup didn't match the one in the lockfile, Bundler would itself replace the current process with exec and erase all of the environment modifications we made, resulting in a guaranteed crash.

I initially tried to fix it by only setting BUNDLER_VERSION, which indeed prevents the restarts. However, as I was testing, I noticed something weird. Despite setting BUNDLER_VERSION when running bundle install in the composed bundle, the resulting .ruby-lsp/Gemfile.lock would still lock to a Bundler version different than the top level lockfile. It would prevent the restart, but it would lock the bundle using the version that was required during setup.

The only way I found to make Bundler both not restart and create a .ruby-lsp/Gemfile.lock that matches the same locked Bundler version as the main lockfile was to pass in the version argument.

If you have more context on Bundler and what a more adequate way of fixing this is, I'm happy to change our approach. Maybe the fact that it locks the composed bundle to a different version is irrelevant and we can just set BUNDLER_VERSION.

I'd love to fully escape having to worry about the binstubs because we have no guarantees about what it supports.

[mislav]

@vinistock Thank you for taking time to respond in-depth! I did not know that there were as complicated edge-cases as what you are describing, and I must admit I do not have a suggestion about how this could be handled better. I do know that Rubygems binstubs will always have the comment # This file was generated by RubyGems., which you could use to test whether a binstub accepts the magic _<version>_ argument.