Use env shebangs for RubyGems installs#4126
Merged
Merged
Conversation
RubyGems bin wrappers hardcode the Ruby used at install time. With Nix-style Ruby installs, that path can later be garbage-collected or replaced, leaving wrappers like ruby-lsp and bundle pointing at a stale store path. Ruby LSP already activates the project Ruby environment before installing or launching the server, so install the bootstrap ruby-lsp gem and any missing Bundler versions with RubyGems' env-shebang option. This lets generated wrappers resolve ruby from the activated PATH instead. Bundler project binstubs already use env shebangs by default; this makes the RubyGems bin wrappers Ruby LSP relies on behave similarly.
pcasaretto
approved these changes
Jun 8, 2026
pcasaretto
left a comment
There was a problem hiding this comment.
Thanks for the fix, Josh. I tested this branch locally and this looks good to me.
Validation performed:
- Ruby-side regression coverage passes:
test/setup_bundler_test.rbcompleted with 41 runs, 189 assertions, and 0 failures/errors when run in a Nix shell withlibyaml/pkg-configavailable forpsych. - VS Code extension code compiles successfully.
- The PR-specific VS Code assertions for installing/updating
ruby-lspwith--env-shebangpass. I had to run from a short/tmpworktree because the deeper macOS path hit the Unix socket path length limit in vscode-test; unrelated Chruby/debugger environment tests still failed in that local setup, but the assertions added by this PR passed. - Manual RubyGems verification confirms the generated
ruby-lspwrapper starts with#!/usr/bin/env rubywhen installed with--env-shebang.
This addresses the Nix/Ruby refresh failure mode we saw where generated binstubs captured an absolute stale Nix store Ruby path. The main boundary to keep in mind is that this prevents newly installed/updated wrappers from going stale; existing stale binstubs still need to be regenerated by an install/update/pristine path. That is an acceptable scope for this PR.
![]()
rafaelfranca
approved these changes
Jun 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
RubyGems bin wrappers hardcode the Ruby used at install time. With Nix-style Ruby installs, that path can later be garbage-collected or replaced, leaving wrappers like ruby-lsp and bundle pointing at a stale store path.
Implementation
Ruby LSP already activates the project Ruby environment before installing or launching the server, so install the bootstrap ruby-lsp gem and any missing Bundler versions with RubyGems' env-shebang option. This lets generated wrappers resolve ruby from the activated PATH instead.
Bundler project binstubs already use env shebangs by default; this makes the RubyGems bin wrappers Ruby LSP relies on behave similarly.
Automated Tests
Yes.
Manual Tests
In a clean project, ruby-lsp and bundler should have
#!/usr/bin/env rubyas the shebang.