Installing Python packages in $HOME

by Raphaël Barrois
in Python

tagged Python

So you've become quite familiar with some Python-developed tools, and have installed them on all your computers.

For a new project, you get an account on a new server; alas, your favorite tools isn't installed there. And you don't have root access. How can you remedy to this issue?

Note

This recipe also applies to installing packages on your personal laptop, and should be preferred over sudo pip install foo.

First, check if the sysadmin can install the distribution-provided package for your program. This is the sanest way to ensure updates to that tool are properly installed, and increases the chances to get your tool installed on other hosts.

If that's not possible, you'll have to install this by hand.

Please, avoid virtualenv here

If you're a Python developer, chances are you're already utilizing virtualenv a lot:

  • It allows to split development environments, making dependency tracking easier
  • It means that broken dependencies can be installed without polluting the system
  • It doesn't require root access to install new packages

Nevertheless, it's not exactly the right tool for this issue:

  • Virtualenvs cannot be stacked, which means that you would have to install your tool in each and every virtualenv you create. virtualenvwrapper might help through its hook system, but we'd be getting into dark magic for a simple use case
  • You may wish to use the tool without having to call . ~/.venvs/foo/bin/activate everytime

Enter install --user

The key solution to all this is the --user option to pip and easy_install install command:

$ pip install --user uconf
$ ls ~/.local/bin
uconf*

Once your package has been installed to ~/.local, you can make it available by inserting the following lines to your .zshrc / .bashrc:

export PYTHONPATH="${PYTHONPATH}:${HOME}/.local/lib/python2.7/site-packages"
export PATH="${PATH}:${HOME}/.local/bin"

Rationale

A common question regarding this scheme is: "Why should I install packages into $HOME instead of sudo + system-wide"?

A basic answer is: "You won't always have root" (and using exploits is not an option here).

A more realistic reason is that the Use standard ways of installing tools into custom locations process can be ported to other languages / frameworks easily, thus meaning that you only have one place for local tools: .local.

Actually, this has always been the way to experiment with compiled programs; why should compiled programs be any different?