1

I know it's possible to choose which Python version to check e.g. in vim.rc as per this SO answer, but can I do it per project? Using e.g. virtualenv or a configuration file?

Community
  • 1
  • 1
geckon
  • 8,316
  • 4
  • 35
  • 59
  • 2
    From the [FAQ](https://github.com/vim-syntastic/syntastic#faqpython): run Vim from `virtualenv` or `pyenv`. Install the relevant linters in the virtual environment. – Sato Katsura Feb 01 '17 at 08:27
  • @SatoKatsura Thanks. I ended up using this. If you add it as an answer, I'll accept it. – geckon Feb 03 '17 at 16:21

1 Answers1

2

It all depends on how you define "this is a project".

Several of us have been providing local vimrc plugins where a project definition is "all the files in this directory and its subdirectories". See this answer for more details and alternatives solutions on the subject: Vim: apply settings on files in directory

Note that lately I've been working on a different (and more lightweight) way (in most cases) to specify what a project is: https://github.com/LucHermitte/lh-vim-lib/blob/master/doc/Project.md (This is still highly experimental).

Reading the answer you've linked to... It only speaks about a global variable that permits to tune the behaviour of the plugin. If there was no other way but tuning this global option, you'd have needed to reset this global variable unconditionally in the local vimrc, or on a BufEnter autocommand. Fortunately, syntastic is project aware thanks to buffer local variables -- @lcd047 corrected me on this topic. This means that instead of resetting a global variable, you could instead set a buffer local variable depending on the current directory (or any other heuristic you could define in an autocommand -- without these plugins, you could simply listen for BufNew and BufRead event, but this won't support migration among machines, directories, etc).

Note that my local-vimrc plugin sources the current local vimrc configuration file every time we enter a buffer matching that configuration file. This means that if you don't add an anti-reinclusion guard, b:syntastic_python_python_exec would be reset every time you enter a buffer for which it has been defined. It shouldn't be that problematic here. Note also that I don't know how alternative plugins proceed.

Community
  • 1
  • 1
Luc Hermitte
  • 31,979
  • 7
  • 69
  • 83
  • 2
    _Unfortunately it's yet another plugin that considers we never work on multiple projects that require different settings._ - Now, if only people would read the manual before making definitive statements like this, we'd live in a better world. Syntastic _does_ pay attention to a local variable `b:syntastic_python_python_exec`. However, the solution mentioned in comments by @SatoKatsura is preferred these days, since it works for all checkers, not just for `python`. – lcd047 Feb 01 '17 at 15:59
  • 1
    @lcd047, My mistake then. I've drawn incorrect conclusions from the other post. I'll edit my message. Thanks for the correction. – Luc Hermitte Feb 01 '17 at 17:05