'bundle install' fails on Gentoo: Could not find command "_2.4.22_" #3022
Comments
jameslikeslinux
added
bug
|
Thank you for the bug report! Figuring out all possible scenarios for these binstubs is proving quite the adventure 😅. Please bare with me as I try to find a solution that is generic enough. Essentially, your scenario seems like the exact opposite of the other bugs reported. In the other cases, users had custom binstubs under Do you do anything to have |
|
It seems that the I’m curious about the decision to rely on undocumented, special arguments in this project. Based on my observations, the RubyGems wrapper uses the str = ARGV.first
if str
str = str.b[/\A_(.*)_\z/, 1]
if str and Gem::Version.correct?(str)
version = str
ENV['BUNDLER_VERSION'] = str
ARGV.shift
end
end Wouldn’t it be more straightforward to set |
ruby-lsp calls bundle with an undocumented version number argument supported by RubyGems binstubs. Portage binstubs don't support this. Use a wrapper to throw away the version number argument. See: Shopify/ruby-lsp#3022
ruby-lsp doesn't execute `bundle` directly. No, that would be the obvious unix way. Instead it assumes it's ruby and passes it to `ruby` instead. See: Shopify/ruby-lsp#3022
|
That's not all the binstub does. It uses the version you pass to eagerly activate the Bundler spec. Gem.activate_bin_path('bundler', 'bundle', version)To compose the bundle that the Ruby LSP uses, passing However, it did not ensure that the composed bundle was built using the same version of Bundler as the main application. The reason is because, if you don't pass a version, the RubyGems stub eagerly activates the spec of the latest Bundler version. That would lead to the main app being locked to one version of Bundler and our composed bundle being locked to a different one, which can also lead to issues. Only by passing the version argument can we ensure that the right spec of Bundler is eagerly activated and the composed bundle gets locked to the expected version. Our first fix used The hope using |
Description
Gentoo Portage generates binstubs using a custom library, resulting in
/usr/bin/bundlehaving the following structure:This implementation does not support the
_VERSION_argument used by standard RubyGems binstubs. Previously, I resolved this by installing a user instance of Bundler in my home directory and placing a standard binstub in~/bin, which was included in myPATH.However, starting with ruby-lsp 0.23, the
bundlelookup behavior changed from usingPATHto relying solely onGem.default_bindir(#2987), which on my system resolves to:This change makes it difficult to specify a custom Bundler instance, which limits the flexibility typically offered by being able to modify the
PATHon Linux and Windows systems.Ruby LSP Information
VS Code Version
1.96.1
Ruby LSP Extension Version
0.8.16
Ruby LSP Server Version
Unknown
Ruby LSP Addons
Ruby Version
3.2.5
Ruby Version Manager
none
Installed Extensions
Click to expand
Ruby LSP Settings
Click to expand
Workspace
{}User
{ "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": "auto" }, "customRubyCommand": "", "formatter": "auto", "linters": null, "bundleGemfile": "", "testTimeout": 30, "branch": "", "pullDiagnosticsOn": "both", "useBundlerCompose": false, "bypassTypechecker": false, "rubyExecutablePath": "", "indexing": {}, "erbSupport": true, "featureFlags": {} }Reproduction steps
Code snippet or error message
The text was updated successfully, but these errors were encountered: