Linter uses a different version of Rubocop from my Gemfile

[jetpacmonkey]

Is there any way to specify what version of Rubocop to run? I have 0.34.2 in my Gemfile.lock, but it appears that SublimeLinter is using 0.35.1.

[reconbot]

It has to do with your path.

[jetpacmonkey]

I set "chdir": "${project}", and the Gemfile.lock is at the top level. I assume I'm missing something else?

[reconbot]

Are you using rvm or chruby? Are you using Bash? It doesn't pay attention to your gemfile lock, it will use the executables that are in your path environment variable.

[joshmfrankel]

As @reconbot mentioned SublimeLinter doesn't see your gemfile.lock. I'm using rvm and in my setup the following path is accurate to my rubocop installation: /Users/jfrankel/.rvm/gems/ruby-2.2.1/bin.

Additionally, if you are using rvm you could setup a gemset and then install the specific version of rubocop that you require. https://rvm.io/gemsets/basics. That would allow you to switch back and forth between versions. Though I would just recommend using the newest version honestly.

[alessandro-fazzi]

I'd like to spend a couple of thoughts about Gemfile or, as a better take, Bundler.

First of all I think that it's not easily recommendable to use always the newest version. Now I'm not interested in emerging those big legacy project written in ruby 1.9.2; but I noticed a fully linted project with ruby 2.2.3 and rubocop 0.35.1 which once switched to rubocop 0.37.1 had an interesting number of lint warning and moreover an unsupported option inside .rubocop.yml

Error: obsolete parameter RunRailsCops (for AllCops) found in /Users/fuzzy/dev/mua_server/.rubocop.yml
Use the following configuration instead:
Rails:
  Enabled: true

Sometimes upgrading is the way to go, but when you are not soloing a project, the project is big and on and on...you're not always a snap away from the goal.

In depth analysis of my path and rbenv

~/dev/mua_server ·  git:(master)
⟩ echo $PATH                                                        [ruby 2.2.3]
/Applications/Postgres.app/Contents/Versions/9.3/bin /Users/fuzzy/node_modules/.bin ./bin /usr/local/heroku/bin /usr/local/mysql/bin /Users/fuzzy/.rbenv/shims /usr/local/bin /usr/bin /bin /usr/local/sbin /usr/sbin /sbin

~/dev/mua_server ·  git:(master)
⟩ rubocop --version                                                         [ruby 2.2.3]
0.35.1

~/dev/mua_server ·  git:(master)
⟩ which rubocop                                                             [ruby 2.2.3]
./bin/rubocop

As you can see my shell is using the binstub as I told it.

~/dev/mua_server ·  git:(master)
⟩ cd app                                                                    [ruby 2.2.3]

~/dev/mua_server/app ·  git:(master)
⟩ rubocop --version                                                         [ruby 2.2.3]
0.35.1

~/dev/mua_server/app ·  git:(master)
⟩ which rubocop                                                             [ruby 2.2.3]
/Users/fuzzy/.rbenv/shims/rubocop

Here I have a little magic inside my Fish shell: it's no more using binstubs, because I left the root of the project, but my shell is silently wrapping rubocop inside a bundle exec. Let's see:

~/dev/mua_server/app ·  git:(master)
⟩ /Users/fuzzy/.rbenv/shims/ruby -S rubocop --version                       [ruby 2.2.3]
0.37.0

If you're asking from where the hell it's taking that version:

~/dev/mua_server ·  git:(master)
⟩ rbenv whence rubocop                                                      [ruby 2.2.3]
1.9.3-p374
1.9.3-p551
2.1.1
2.1.2
2.1.5
2.2.0
2.2.1
2.2.2
2.2.3
2.3.0

The last one, 2.3.0, is my global version...so:

~
⟩ rubocop --version                                                         [ruby 2.3.0]
0.37.1

Voilà! The command /Users/fuzzy/.rbenv/shims/ruby -S rubocop used by rubocop-linter is getting rubocop from my global version, I bet! Let's try to change my global version: rbenv global 2.2.3

~/dev/mua_server ·  git:(master)
⟩ /Users/fuzzy/.rbenv/shims/ruby -S rubocop --version               [ruby 2.2.3]
0.37.0

O_O WAAAAT? The only ways to get the right version are:

~/dev/mua_server ·  git:(master)
⟩ bundle exec /Users/fuzzy/.rbenv/shims/ruby -S rubocop --version   [ruby 2.2.3]
0.35.1

or

~/dev/mua_server ·  git:(master)
⟩ /Users/fuzzy/.rbenv/shims/rubocop --version                       [ruby 2.2.3]
0.35.1

Differences aren't so small:

~/dev/mua_server ·  git:(master)
⟩ bundle exec /Users/fuzzy/.rbenv/shims/ruby -S rubocop .                   [ruby 2.2.3]
Inspecting 97 files
.................................................................................................

97 files inspected, no offenses detected

VS

~/dev/mua_server ·  git:(master)
⟩ /Users/fuzzy/.rbenv/shims/ruby -S rubocop .                               [ruby 2.2.3]
Error: obsolete parameter RunRailsCops (for AllCops) found in /Users/fuzzy/dev/mua_server/.rubocop.yml
Use the following configuration instead:
Rails:
  Enabled: true

:) Probably me and my colleagues are inside an edge case, I don't know. But I know that rarely we've seen a Ruby project not using bundler and no one can work on a Rails project without bundler.

Even more: I'm not just right here with a solution, but I just hope that my analysis could be useful for the discussion and almost to understand if I'm doing something wrong.

Thanks for your -long lasting- attention :)

[joshmfrankel]

Good point about not always being able to use the newest version, I hadn't considered that. Definitely depends on the requirements of your application.

Additionally, I can confirm that prepending the rubocop command with bundle exec in rvm also uses the version specified in the Gemfile. @pioneerskies nice find.

[alessandro-fazzi]

@joshmfrankel thanks for your time and attention.

I wish it should be a good find for a number devs. And obviously I hope it could be an unobtrusive implementation, even an opt-in one.

Looking forward to hear some more opinions.

Cheers

[dazza-codes]

I have a .rubocop.yml file with an inherit_gem: clause and the gem is only available in the app bundle. I need a way to specify details in a .sublime-project or a .sublimelinterrc so that the linter will run bundle exec rubocop (so it can find the bundled gem to be inherited).

Can anyone tell me how to do this? When I look at the Packages/User/SublimeLinter.sublime-settings for rubocop, there is no cmd option, e.g.

           "rubocop": {
                "@disable": false,
                "args": [],
                "excludes": []
            },

I've been messing around with my $PATH, but it's so painful to get this right, just for one project. I used bundle install --binstubs .binstubs and added the .binstubs to the begging of my $PATH, but the linter doesn't use .binstubs/rubocop. It would be great if the linter could detect and use values from .bundle/config, like:

---
BUNDLE_BIN: ".binstubs"
BUNDLE_PATH: ".gems"
BUNDLE_DISABLE_SHARED_GEMS: true

The current command can be seen in the console (maybe debug needs to be enabled), i.e.

SublimeLinter: rubocop: some_ruby_file.rb ['ruby', '-S', 'rubocop', '--format', 'emacs', '--force-exclusion', '--stdin', 'some_ruby_file.rb'] 

So, I want to replace that with something like:

SublimeLinter: rubocop: some_ruby_file.rb ["${project}/.binstubs/rubocop", '--format', 'emacs', '--force-exclusion', '--stdin', 'some_ruby_file.rb']

I tried to change the rubocop_command in ~/.config/sublime-text-3/Packages/User/RuboCop.sublime-settings, but that doesn't work. The cmd seems to hard-code the command in https://github.com/SublimeLinter/SublimeLinter-rubocop/blob/master/linter.py#L44

[piotrpawlik]

@darrenleeweber Have similar issue to yours. Any luck solving it?

[den-stripe]

I believe this seems like a right way to solve this problem https://github.com/SublimeLinter/SublimeLinter-rubocop/issues/13#issuecomment-262299289

Any objections for bundle exec instead of ruby -S?

@reconbot

[ljkbennett]

This has been resolved by https://github.com/SublimeLinter/SublimeLinter-rubocop/pull/40