Executables and how we specify them

[reconbot]

I'm at the limit of my sublime linter knowledge. This will affect #9.

In ruby land we have ton of different ways to configure our setups and choose ruby versions and library paths. I'd like to support more of them.

Current Support

• [x] a system wide rubocop and a system wide ruby (rubocop)
• [ ] a bundler chosen rubocop (to override a system wide rubocop per project) bundle exec rubocop
• [x] a rvm setup - still debugging but ruby-rvm-env -S rubocop works as does some symlinking see https://github.com/wayneeseguin/rvm/issues/3274#issuecomment-71536404 chooses the right ruby and the gemset's rubocop this works around rvm's hooking to cd
• [x] chruby (I don't use it so I don't know our support)
• [x] rbenv solved using path settings and it's binstubs (I also don't use it so I can't verify it's support)
• [x] bundler + one of the ruby switchers (eg for rvm ruby-rvm-env -S bundle exec rubocop)

I've included the commands we'd need to run for the situations I know of. What's a good pattern to allow configuration of this?

[groteworld]

So you have a couple choices off the cuff:

1. A setting variable that is set to some value that denotes the setup (E.x. "rbenv", "system", "rvm+bundler")
2. Have the linter determine best one (would have to be opinionated on what's the best, and would probably want override like number 1)

Since 1, so far, seems like a common denominator it's a good idea to maybe start. Like you said, this is a combinatoric problem of the ruby eco.

[jawshooah]

Correct me if I'm wrong, but might not #14 help with this? Inheriting from RubyLinter should take care of hooking the linter up with rbenv or rvm (using rvm-auto-ruby).

Support for bundler should probably be added to RubyLinter in any case, since it should be common to all Ruby linters.

[reconbot]

It would =)

[reconbot]

Thanks to @jawshooah our latest version supports rvm and chruby. Bundler is next.

[reconbot]

I'm going to close this for now as we haven't had anyone complain about bundlr in a while.

[oliviertassinari]

we haven't had anyone complain about bundlr in a while.

Well, I ended-up doing the following change to get it working:

-command = ['ruby', '-S', 'rubocop', '--format', 'emacs']
+command = ['bundle', 'exec', 'ruby', '-S', 'rubocop', '--format', 'emacs']

[rpbaptist]

@oliviertassinari Can you let me know where I can add this?

Answering my own question: https://github.com/SublimeLinter/SublimeLinter-rubocop/blob/master/linter.py#L44

[groteworld]

@rpbaptist Oliver's changes were made here, though note that this is a temporary fix to the issue, and will prevent you from being able to getting automatic updates from SublimeLinter-rubocop.

[felixyz]

I think Bundler support or a way to easily modify the command without having to hack linter.py would be very useful. In our case, we're using CodeClimate which uses a fixed version of Rubocop, usually lagging behind the latest release. To get the same warnings locally, we have to set the same Rubocop version in our Gemfile. Of course, we could force everyone to have the correct version of Rubocop installed globally, but that's unwieldy. So consider this a +1 for sorting this out.

[felixyz]

Perhaps this should be handled by SublimeLinter itself, if the preferred solution is simply to let users set their own command (like Sublime RuboCop does)?