Skip to content

Instantly share code, notes, and snippets.

@jottr
Last active December 28, 2021 12:29
Show Gist options
  • Save jottr/e32d976a5bc4f52a55f4d9f18a11d5cb to your computer and use it in GitHub Desktop.
Save jottr/e32d976a5bc4f52a55f4d9f18a11d5cb to your computer and use it in GitHub Desktop.

This is cobbled together and extended from https://github.com/zchee/deoplete-jedi/wiki/Setting-up-Python-for-Neovim

Setting up Python for Neovim and Youcompleteme

Neovim requires a package to be installed for Python plugins to work. You really should read :h nvim-python to supplement the info on this page.

# Make sure you export the correct environment for youcompleteme:

export PYTHON_CONFIGURE_OPTS="--enable-unicode=ucs4 --enable-framework"
pyenv install 2.7.11
pyenv install 3.4.4

pyenv virtualenv 2.7.11 neovim2
pyenv virtualenv 3.4.4 neovim3

pyenv activate neovim2
pip install neovim
pyenv which python  # Note the path

pyenv activate neovim3
pip install neovim
pyenv which python  # Note the path

# The following is optional, and the neovim3 env is still active
# This allows flake8 to be available to linter plugins regardless
# of what env is currently active.  Repeat this pattern for other
# packages that provide cli programs that are used in Neovim.
pip install flake8
ln -s `pyenv which flake8` ~/bin/flake8  # Assumes that $HOME/bin is in $PATH

Now that you've noted the interpreter paths, add the following to your init.vim file:

let g:python_host_prog = '/full/path/to/neovim2/bin/python'
let g:python3_host_prog = '/full/path/to/neovim3/bin/python'

Now make sure you rebuild YouCompleteMe as documented here.

Tips for using pyenv

  • Ensure you have the prerequisites installed.
  • Installing pyenv with homebrew is unreliable. Use pyenv-installer instead.
  • There is a final step that's printed to the terminal after installing pyenv and it's important!
  • To confirm you have pyenv correctly installed, run which pyenv. It should print a shell function, not a file path.
  • Run pyenv doctor to avoid surprises.
  • pyenv global can be thought of as altering the $PATH to include the specified versions' bin directory. This only works while pyenv is active.
  • pyenv shell is the same as above, but for the current session.
  • pyenv local is the same as above, but it writes a .python-version file in the current directory. It allows the specified versions to be automatically set when you enter the directory, and unset when you leave it. Very convenient for projects.
  • You will want to add .python-version to your global .gitignore file.
  • pyenv shell --unset will reset the session's Python versions.
  • pyenv activate venvname differs from pyenv shell venvname in that only one $VIRTUAL_ENV can be active at a time.
  • pyenv deactivate deactivates the virtual environment.
  • pyenv versions lists the versions you have installed. system is a special case pointing to Python versions that were originally found in $PATH. Virtual environment names are listed as versions.

Why you shouldn't use sudo

Unless you know what you're doing, the system installed Python interpreters should remain pristine and only contain packages that were installed via the OS's package manager (read: not pip). sudo in front of pip install should make you cringe any time it's recommended.

Some distros use separate locations for system packages and user packages, but the potential to mess things up is increased when you use sudo. On distros that don't make a distinction between system and user packages, it's possible to upgrade system packages with sudo pip install -U. Or the reverse could happen and you'll downgrade packages installed with pip. There is also the issue of non-Python system packages that may require the specific versions of Python packages that were built for the distro. The point is, you will have two package managers competing to decide what's new or old.

A very common example of what can go wrong: sudo pip install --upgrade pip. It is a problem many Python developers encounter. This problem occurs more than it should and renders all Python programs installed in the system bin directories to be broken.

If you can't honestly say that you know how Python packages are laid out or what your system's Python dependencies are, and enjoy having a stable, error-free Python installation, leave the system Python installations alone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment