Skip to content

Conversation

@nulty
Copy link

@nulty nulty commented Mar 15, 2025

Using nvim on different projects with different ruby versions is made harder when I have to go to the Mason installed binaries and update the shebang so the formatter/lsp/whatever works across ruby versions.

Passing the --env-shebang options allows me to run the package using the currently enabled ruby versions.

Rubygems gem install command-reference

Could fix this issue #1292

@phantomwhale
Copy link

Have moved onto this fork, and can confirm the strange issues I was having using Mason + chruby went away after using this fix 👌

@williamboman
Copy link
Member

This actually breaks things for me when using rbenv. The shebang without this flag is #!/Users/william/.rbenv/versions/3.4.4/bin/ruby, which ends up executing the correct Ruby version no matter what version I currently have active. Using the #!/usr/bin/env ruby variant (this PR) it starts breaking because it executes with the wrong Ruby version.

I'm not really following how #!/usr/bin/env ruby would help things - wouldn't that just guarantee that this issue happens as soon as you swap Ruby versions?

@phantomwhale
Copy link

I'll admit, my knowledge in this area is a quite hazy. But chruby works by shifting the PATH env to point at the correct ruby version (no shims) so I'm guessing using env binstubs means you'll always be picking up the appropriate version of ruby based on how the PATH has been set?

Perhaps the fundamental approach of rbenv requires different approaches here (?) Not sure. Might explain why I frequently have strange ruby issues around Mason tooling that I would have expected to be much more "visible" (I'm guessing more people still use "shim" approaches, such as rbenv, asdf or mise etc... than are using chruby?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants