Multiple Python versions

[ansipunk]

I'm on Fedora 33 with Python 3.9. It works just fine with every project that uses explicitly python3.9 or implicit python(3)?, both with and without a virtual environment.

However, I do have a project that requires 3.7 and won't run on newer versions and I'd like to keep using awesome python-language-server and asynchronous deoplete as regular synchronous jedi tends to block the whole editor's thread with bigger libraries like SQLAlchemy, but some of plugins just won't let me.

Sure thing I did install neovim and pynvim packages in my virtual environment. echo exepath('python3') returns /home/euromancer/source/airflow/.venv/bin/python3 and has('pythonx') returns 1, however, has('python') returns 0. Nothing mysterious in my vimrc, just lsp#register_server() and few configs for lsp. Nothing special on deoplete as well.

I've quickly checked the source code, however, I'm not very familiar with vimscript nor vim plugins nor probably anything. Although I think it might be linked to list of python executables to check availability.

Sure thing all the packages and plugins and everything (except Python 3.7 lol) are up to date.

My completion-related plugins are:

• Shougo/deoplete.nvim
• prabirshrestha/vim-lsp
• lighttiger2505/deoplete-vim-lsp

And I do have roxma/nvim-yarp and roxma/vim-hug-neovim-rpc.

Never tested it with neovim tho, as I prefer vim for some whatever reasons I find hard to point out.

I did install neovim and pynvim and python-language-server on the global Python 3.7 installation.

The issue was present on Ubuntu 20.04 with Python 3.8 too.

[Shougo]

You need to install pynvim package in Vim python3 environment. It may be complex. But it is Vim feature. I recommend for you to use neovim if you don't understand Vim behavior.

[Shougo]

Your python points to venv, but Vim Python3 is not same. I think you understand Python environment behavior. Because you use jedi for Python.

[ansipunk]

As you pointed out, :py3 print(sys.path) returns ['/usr/lib64/python39.zip', '/usr/lib64/python3.9', '/usr/lib64/python3.9/lib-dynload', '_vim_path_'] therefore it indeed uses incorrect Python package path. Although installing neovim package globally with sudo for Python 3.9 did not resolve the issue. So you can't see any options for me but switching to Neovim, can you? @Shougo

[Shougo]

You must work :py3 import pynvim for vim-hug-neovim-rpc and deoplete. You know the correct way. pynvim package is installed in the Python, really?

[Shougo]

Hm. /usr/lib/python3.9/site-packages is not included in your sys.path. It is your environment problem. It is not the project problem.

[ansipunk]

ModuleNotFoundError within 3.7 virtual environment, although just 👌🏻 with global Python. pynvim is installed in every virtual environment and every global Python installation globally. Like, for real.

:py3 import site; print(site.getsitepackages()) returns this: ['/home/euromancer/source/airflow/.venv/lib64/python3.9/site-packages', '/home/euromancer/source/airflow/.venv/lib/python3.9/site-packages']

~/source/airflow/ $ ls .venv/lib   # returns 'python3.7'
~/source/airflow/ $ master ls .venv/lib64    # returns 'python3.7'

For some reason the editor or the plugin incorrectly assumes package path.

[ansipunk]

Please keep in mind that the issue is only present when using non-standard Python version in a virtual environment, 3.7 against standard 3.9 in my case.

[ansipunk]

I'm closing the issue as it is only related to the editor itself. Probably have to make a switch to Neovim.

Running :py3 import site; print(site.getsitepackages()) in a clean Vim without any plugins or configs and in a Python 3.7 virtual environment returns just the same result: ['/home/euromancer/source/airflow/.venv/lib64/python3.9/site-packages', '/home/euromancer/source/airflow/.venv/lib/python3.9/site-packages']

[ansipunk]

I tried the following hack:

function! g:ActivateVirtualenv()
    if !empty($VIRTUAL_ENV)
        execute 'VirtualEnvActivate'
    endif
endfunction

augroup vimrc
  au VimEnter * g:ActivateVirtualenv()
augroup END

Although it did not work out since vim-hug-neovim-rpc is initialized before autocmd run. I used jmcantrell/vim-virtualenv plugin. I'd be happy if you had any suggestions on how to do this hack properly. I wonder if Shougo/dein.vim supports running user-defined functions before initializing plugins, however, I'm not familiar with any of Shougo plugins as they are pretty difficult to understand to an unexperienced user like me.

@Shougo

[Shougo]

I wonder if Shougo/dein.vim supports running user-defined functions before initializing plugins, however, I'm not familiar with any of Shougo plugins as they are pretty difficult to understand to an unexperienced user like me.

It is possible. But you should more understand dein's behavior. I don't have time to explain the behavior and make the code. I am not free.

Hint: depends plugin is loaded before deoplete.