Vscode-ruby: Ruby version not correctly parsed when using RVM

Created on 18 May 2020 · 8Comments · Source: rubyide/vscode-ruby

Your environment

vscode-ruby version: 0.27.0
Ruby version: 2.7.1
Ruby version manager (if any): RVM
VS Code version: 1.45.1
Operating System: MacOS 10.15.4
Using language server? (eg useLanguageServer is true in your configuration?) true

Expected behavior

When linting or formatting (like with Rubocop) and using bundler, no errors are outputted and formatting behavior works.

Actual behavior

Workspace settings:

{
  "ruby.useBundler": true,
  "ruby.useLanguageServer": true,
  "ruby.codeCompletion": false,
  "ruby.intellisense": false,
  "ruby.format": "rubocop",
  "ruby.lint": {
    "rubocop": {
      "useBundler": true
    }
  }
}

Directory structure:

|- app.rb
|- Gemfile
|- Gemfile.lock

The following error is logged due to the wrong version of Ruby being loaded:

Lint: executing bundle exec rubocop -s /Users/admin/my-app/app.rb -f json...
/Users/admin/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.4/lib/bundler/definition.rb:495:in `validate_ruby!': Your Ruby version is 2.6.3, but your Gemfile specified 2.7.1 (Bundler::RubyVersionMismatch)
    from /Users/admin/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.4/lib/bundler/definition.rb:470:in `validate_runtime!'
    from /Users/admin/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.4/lib/bundler.rb:143:in `setup'
    from /Users/admin/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.4/lib/bundler/setup.rb:20:in `block in <top (required)>'
    from /Users/admin/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.4/lib/bundler/ui/shell.rb:136:in `with_level'
    from /Users/admin/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.4/lib/bundler/ui/shell.rb:88:in `silence'
    from /Users/admin/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.4/lib/bundler/setup.rb:20:in `<top (required)>'
    from /Users/admin/.rvm/rubies/ruby-2.6.3/lib/ruby/site_ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
    from /Users/admin/.rvm/rubies/ruby-2.6.3/lib/ruby/site_ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'

The content of app.rb itself is empty, meaning it's not affected by the source code.

Hypothesis

When RVM is loaded, it aliases the rvm command as a function and sets up appropriate environment variables (like RUBY_VERSION) which is usually set at a user's ~/.profile or ~/.bash_profile dotfile. However those dotfiles are only sourced when running a shell with the login flag /bin/bash -l, otherwise RVM isn't loaded at all.

It seems that the fix would be to change this line to also pass the -l flag https://github.com/rubyide/vscode-ruby/blob/master/packages/vscode-ruby-common/src/environment.ts#L44.

I haven't tested it yet but it may also require a cd . statement to trigger RVM's automatic Ruby loading when changing directories.

stale

Source

ferdaber

👍2

Most helpful comment

@Yorkshireman a workaround is to open the extension folder, which is usually under ~/.vscode/extensions/rebornix.ruby-xxx (xxx is the current extension version), and change this file: dist/server/shims/env.bin.{shell}.sh (shell will be whatever your default shell is). It'll look something like:

#!/bin/zsh -i
export

You want to add the -l flag in the hashbang header:

#!/bin/zsh -i -l
export

ferdaber on 22 May 2020

🎉7 ❤5

All 8 comments

I'm having the same problem.

Yorkshireman on 22 May 2020

#!/bin/zsh -i
export

You want to add the -l flag in the hashbang header:

#!/bin/zsh -i -l
export

ferdaber on 22 May 2020

🎉7 ❤5

It worked! Brilliant, thanks @ferdaber

Yorkshireman on 22 May 2020

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

github-actions[bot] on 8 Aug 2020

Great workaround @ferdaber ! Is there something preventing the addition of the -l flag in the shebang for everyone? I could drop a PR if it's just that...

nicolasrouanne on 20 Nov 2020

I took a different route an changed the function getProcessEnv() to change the ruby versions according to the settings in vscode.

bjelline on 29 Nov 2020

Great workaround @ferdaber ! Is there something preventing the addition of the -l flag in the shebang for everyone? I could drop a PR if it's just that...

I think as long as -l is universal enough that most shells use the same letter for that login flag, it's fine. It does seem like the templating assumes that all shells share the same flag behavior.

ferdaber on 1 Dec 2020