Support for running in an existing virtualenv

[mjtorn]

Hi!

I sometimes wish I could be bothered to script the installation of my favorite Python development modules somewhere (the ones that aren't in every requirements.txt), but I don't know where would be the best place. I like your approach, but I always use separate virtualenvs for different projects. That's why I added this feature to your code.

Passed manual testing.

PS. I didn't use the default shell-script mechanism you have because it doesn't work on ZSH (and because it's not what I do), but maybe this programmatic running of pip might give you ideas on how to implement that stuff in Python. I'm sure virtualenvs beside (obviously) pip can be called programmatically. Just an idea.

Thanks!

[roxma]

The duty of this plugin is to provide consistent dependency for other neovim python plugins, and not to pollute the project specific virtualenv (install modules that's not useful to the project).

Event though this plugin is not running in project's virtualenv, for example the jedi library for completion will still work if you activate the project's virtualenv before you start neovim.

I don't understand why you need to run neovim's python plugin on project's virtualenv.

[mjtorn]

I editing a Python project in a neovim virtualenv without the usual jedi and flake8 stuff I use. You're right in that jedi does do autocomplete, but ALE/flake8 does not work. Obviously, because flake8 is missing in Neovim's virtualenv!

Usually I don't consider it "pollution" and most projects will have flake8 anyway, and I'm a creature of habit when something works for me.

If you don't like this PR, no need to merge it. If I end up having the time and mood, maybe I could look into something else. Basically what I didn't like too much about the current way the code works is that it doesn't work on ZSH and it requires interaction.

Automating that, combined with what I usually do, it wasn't a problem for me.

I seem to recall one case where using a specific neovim virtualenv did not work with the project, but that one was a bit different from standard virtualenvs and might be irrelevant to most cases.

Maybe you shouldn't merge this just yet and either I'll keep using my fork for a while and/or see if I can automate a neovim-specific virtualenv with a bunch of stuff I usually like to have with something closer to your current code.

[mjtorn]

One personal preference I might mention is that I have autoenvs, so if there's a neovim-specific virtualenv (with things like flake8 and isort and whatever, which may or may not be used if I'm working in eg. C++) I would like the code to change virtualenvs transparently. I think your shell script does that in Bash, but just saying, so I remember myself if I get back to this :)

[mjtorn]

Maybe this isn't worth the effort, really

[roxma]

FYI

The jedi library doesn't complete for non-venv project if the plugin is running in venv.

So I added support for disabling the venv feature, to use current environment's python2 and python3

let g:python_support_python2_venv = 0
let g:python_support_python3_venv = 0