Using pyright with pyenv and its .python-local feature

[GertBurger]

This is more of a pyenv specific continuation of #4021 and knowledge dump than anything else.

tldr

As per #4021, pyright doesn't and won't execute python in the current working directory and this breaks tools such as pyenv which can depend on the current working directory to dispatch to the correct virtualenv.

Getting pyright and pyenv to play along

So far the workarounds I see are:

1. Set PYENV_VERSION environmental variable to the name of your virtualenv before starting your editor. You can use pyenv shell my_virtual_env or direnv to automate it or any other method you can think of. This might still require you to set pyright's global python.pythonPath to /home/YOUR_USER_NAME/.pyenv/shims/python if your environment's PATH is not setup correctly. Else the default value of python.pythonPath (which is python afaik) should suffice with a default pyenv installation.
2. Create a pyrightconfig.json (or equivalent for your editor) in your project directory and setup either python.pythonPath or some combination of python.venvPath and python.venv so that the actual location of the virtualenv is known by pyright. You can use https://github.com/alefpereira/pyenv-pyright to generate this for you whenever you need it.

All of them require some kind of per project configuration on top of the existing pyenv configuration, which isn't great.

Warning

Any of pyenv's shims configured in pyright's python.pythonPath will ONLY work if you have the PYENV_VERSION environmental variable set. Using values such as /home/USER/.pyenv/versions/VIRTUAL_ENV/bin/python also don't work as they will (likely) resolve to one of pyenv's shims.

Longer explanation

pyenv has 3 main methods for locating the virtualenv the user is expecting (https://github.com/pyenv/pyenv#understanding-python-version-selection):

1. Via PYENV_VERSION environmental variable, as set by pyenv shell my_virtual_env
2. Via .python-version files, as created by pyenv local my_virtual_env
3. Via a user defined global, as set by pyenv global my_virtual_env.

pyright's logic to determine the current virtualenv depends on executing the currently available python located via the environment and from that determine the active virtualenv by interrogating sys.path. This works when the current environment directs pyright to the active virtualenv's python (method 1) as the executing environment variables (PYENV_VERSION) are preserved.

Method 2 however is a more user friendly way of configuring virtualenvs for projects and this depends on the current working directory being where the user executed it from (directly or indirectly via an editor using LSP and pyright).

Related discussions

• coc-pyright sets PYENV_VERSION from .python-version could not be resolved if use pyenv local  fannheyward/coc-pyright#184 (comment) and fannheyward/coc-pyright@77e02e0

[predmijat]

Since few days ago I must do pyenv shell my_venv (or use something like direnv). The trick with pyenv pyright doesn't work any more...is it just me?

[MichalFlyps]

Do you have any solution to pyright to detect current pyenv environment?

My pyright run does not detect the existing and correct $PYENV_VERSION
The only way that works for me is I still need to use the manual path pointing in toml as follows:

[tool.pyright]
# Adapt venvPath and venv to your local pyenv:
venvPath = "path_to_envs"
venv="my_env"

Withtout this, I keep getting a bunch of eg: error: Import "sqlmodel" could not be resolved (reportMissingImports)

Any other options so that this could be comitted to github and every user with different path could use it?

[ghost]

does using shell environment variables work for you?

function nvimvenv {
  if [[ -e "$VIRTUAL_ENV" && -f "$VIRTUAL_ENV/bin/activate" ]]; then
    source "$VIRTUAL_ENV/bin/activate"
    command nvim $@
    deactivate
  else
    command nvim $@
  fi
}

alias vim=nvimvenv
alias nvim=nvimvenv