Plugin does not work when a python virtual env is activated

AxZxP commented 2 years ago

Setup

macOS 10.15
Alacritty 0.10.1
tmux 3.3a
nvim 0.7.0
nvim-tmux-navigation plugin commit 0a084d7

Workflow

I use pipenv to create a python virtual environment. All is good from the :checkhealth point of view. But if I don't source the venv before launching nvim the plugin is working nicely. If I source the venv before launching nvim the plugin stops working. Still, if I run a plugin command manually it works.

`:checkhealth` report when venv is sourced

## Python 3 provider (optional)
  - INFO: Using: g:python3_host_prog = "$HOME/.local/pipx/venvs/python-lsp-server/bin/python"
  - INFO: Executable: /Users/azp/.local/pipx/venvs/python-lsp-server/bin/python
  - INFO: Python version: 3.10.5
  - INFO: pynvim version: 0.4.3
  - OK: Latest pynvim is installed.

## Python virtualenv
  - WARNING: $VIRTUAL_ENV is set to: /Users/azp/.local/share/virtualenvs/tcs-Qsyv8aDE
    And its /bin directory contains: python, python3, python3.10
    But $PATH in subshells yields this python3 executable: /Library/Frameworks/Python.framework/Versions/3.10/bin/python3
    And $PATH in subshells yields this python3.10 executable: /Library/Frameworks/Python.framework/Versions/3.10/bin/python3.10
    So invoking Python may lead to unexpected results.
    - ADVICE:
      - $PATH ambiguities in subshells typically are caused by your shell config overriding the $PATH previously set by the virtualenv. Either prevent them from doing so, or use this workaround: https://vi.stackexchange.com/a/34996

alexghergh commented 2 years ago

Hey,

As far as I see, there is some problems with the Python executable in the virtual environment. I am not completely sure what that means. I also ran a couple of tests, and it seems to work for me in a virtual environment (but I noticed something else strange in my setup, so I will fix that and then try again).

Couple of things to try:

Run the python command inside and outside of the virtual environment (both from neovim). Try something like :python3 -m pip freeze. This should give you a list of packages installed with pip. They should be different inside and outside of the virtual environment. Note that you need the pynvim python package for this to work.
Disable every other plugin, and see if only enabling this plugin works (I suspect that there may be another plugin that depends on Python, and since your setup doesn't correctly detect the Python executable in the virtual environment, it doesn't fully load the plugins following; just an idea)
Try going through this help page and see if anything helps (in case you didn't already do that).

Let me know how it goes, I will also try to run a couple of tests. I suspect again that it's not a plugin issue, but rather a setup issue, as the plugin itself has nothing to do with Python whatsoever.

AxZxP commented 2 years ago

Hey Alex,

I suppose the right command include a ! as a prefix (:!python3 -m pip freeze)?

Setup

Just to recap my setup in case my tests need context :

python is (on Mac especially) linked to the Python 2 executable
python3 relates to the first Python 3 executable found in the PATH. In my case this is python3.10 (hence my default python3)
From the command line and with the venv activated both python and python3 relates to the virtual env executable.

Tests

So this is the results of my tests (I used the fish command :!type -p [python-executable] that output the path of an executable to double-check)

Outside my venv, :!python calls python2 and :!python3 calls my main system python3 executable with no package installed. This is the exact same behaviour that expected in a command prompt.
Inside my venv :!python calls the python executable that is coming from my virtual env. :!python3 is still associated with the system wide python3 executable. This is not the same that In a command prompt.

I don't think it's related to your plugin anyway but rather either my config or the way virtual envs are managed, here by pipenv. When I use python3 -m venv path/to/venv(the standard library tool to create vends), the integration tmux/nvim is perfect. When I use pipenv it mess with your plugin and nothing else and if I use poetry the whole interface is lagging.

alexghergh commented 2 years ago

Hey, sorry for the delayed response! Did you manage to get it working?

I suppose the right command include a ! as a prefix (:!python3 -m pip freeze)?

Yes, I think both work the same (more or less). The python version that neovim runs should be the same as the system python, unless you explicitly configured it otherwise. Nonetheless, run both just in case.

As for the test itself, the normal venv that comes bundled with python works just fine for me, and seems to work for you too. I am not quite familiar with pipenv though, and never worked with poetry, so can't really say much about that.

Could you try one more thing: have a config file (e.g. init.lua) that just initializes the plugin and nothing else. Then try the same tests with 'pipenvandpoetry` (just in case you didn't already do that).

Again, I cannot imagine how such a thing could happen. I wouldn't totally exclude a Neovim bug in itself (with the Lua engine, for example), however that is way out of my area of expertise.

Let me know if I could try helping with anything else.

AxZxP commented 2 years ago

Hi Alex,

I stumbled upon this issue from the plugin you port to neovim. I understood that every python tool that implement a virtual env management feature need to spawn a subshell to make it work.

I didn't try to get all the details related to this and I'm sure there is a way to use pyright with various config files in order to set the correct python path and then get rid off the obligation of activating the virtual env before launching nvim.

But there is a quick solution : pipenv run nvim. For future reference, I test it with poetry and it also works.

Thank you for your help Alex and for this excellent plugin.

alexghergh / nvim-tmux-navigation