Rich's Tongfamily

Ok, this problem has really been bothering me, but I use four levels of python virtualization. I don’t need all of these but they are from history, so they are:

1. Homebrew installation. YOu can install multiple versions of python with brew install python@3.8 for instance. I don’t use this that much, but it lets you have different versions
2. ASDF version manager. On top of that I also use asdf which gives you for each directory a different version of just about everything from python to node to ruby to a per-directory environment variable system. This is probably the system I use the most because it is just an edit of a .tool-versions to get the latest and with requirements.txt you can see what you’ve loaded.
3. Anaconda. On top of that, most machine learning folks use Conda. This let’s you share environments across directories so it is better on storage, but you do have to keep track of your environment
4. Pipenv. Ok, this one is not as popular, but I really started using it for the per-directory feature and also because it has an explicit Pipfile so that you can see what the dependencies are per system. ASDF gives you control over the python you are using, but then you use pip and requirements.txt to control the actual versions.

When Neovim Loses Python

Ok, so the specific problem I’ve been having for a while is that Neovim will complain obscurely that it can’t find Python. The first thing to do is to see if python3 support is compiled into neovim which you get with the command :echo has('python3') and see if you get a 1 back.

What is happening is that you need to pip install neovim in any virtual environment and if neovim doesn’t see it then it throws errors. And it is hard to know why or even to figure out the diagnostics, it turns out there are two things to do inside nvim itself and that is to run a diagnostic checkhealth, this will tell you have a minute to so if it can find a python or not. Then you can actually run a little python script to figure out what it is calling. It basically calls each extension and they print diagnostics. The most important being the location of your Python 3 provider and the path and also if the latest package call pynvim or neovim is installed:

# inside nvim run
:checkhealth
# now you can actually run some code to see if you 
## Python 3 provider (optional)
    - INFO: Using: g:python3_host_prog = "python"
    - INFO: Executable: /Users/rich/.asdf/installs/python/3.10.6/bin/python
    - INFO: Python version: 3.10.6
    - INFO: pynvim version: 0.4.3
    - OK: Latest pynvim is installed.

In my case what I found was something strange instead of pointing to an asdf installation, it pointed to a pipenv installation. It turns out that I must have accidentally typed pipenv into a directory and this silently took over. You can accidentally do this and if there is no Pipfile, there is no indication that it has taken over. So once you see pipenv is activated, you can run a pipenv --rm and it will go away. The other way to tell is to see if PIPENV_ACTIVE is set in the shell. Or you can look at checkhealth again and if you don’t see the note about the pip package, you should install it with pip install neovim Note that the old name of neovim is pynvim which is what is used in the diagnostics:

$ nvim
:checkhealth

## Python 3 provider (optional)
    - INFO: Using: g:python3_host_prog = "/Users/rich/.local/share/virtualenvs/src-hwnz8u0M/bin/python"
    - INFO: Executable: /Users/rich/.local/share/virtualenvs/src-hwnz8u0M/bin/python
    - INFO: Python version: 3.9.14
    - INFO: pynvim version: 0.4.3
    - OK: Latest pynvim is installed.