377

From pip install --help:

--user  Install to the Python user install directory for your platform.
        Typically ~/.local/, or %APPDATA%\Python on Windows.
        (See the Python documentation for site.USER_BASE for full details.)

The documentation for site.USER_BASE is a terrifying wormhole of interesting Unix-like subject matter that I don't understand.

What is the purpose of --user in plain English? Why would installing the package to ~/.local/ matter? Why not just put an executable somewhere in my $PATH?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Rob Truxal
  • 5,856
  • 4
  • 22
  • 39
  • 4
    you can `import site; print site.USER_SITE` to print the install location. For me I got `/${HOME}/.local/lib/python${PY_MAJOR}.${PY_MINOR}/site-packages`. – Trevor Boyd Smith Nov 12 '18 at 17:44
  • 3
    On a host machine, `/usr/local/lib/pythonX.X/dist-packages` is the default directory for packages installed by _pip_. But if one user wants to install user-specific packages, they can use `$ sudo pip3 --user install some_package`. That package will remain unavailable to groups and others who access that host. – noobninja Nov 29 '19 at 02:32

9 Answers9

424

pip defaults to installing Python packages to a system directory (such as /usr/local/lib/python3.4). This requires root access.

--user makes pip install packages in your home directory instead, which doesn't require any special privileges.

  • 4
    Thanks; that makes sense. But is the point of `--user` to make sure that one does not run the package as root? (I'm imagining something similar to like Wireshark/kismet/burpsuite options to set up group-access policies, thereby not allowing all the program-features to run as root. Is that on the right track?) or is the `--user` option just meant to _allow_ the installation without root privileges? If that's the case, why don't I ever use `sudo pip install foo_package`? I've never needed root-privelages to install via pip before. – Rob Truxal Mar 26 '17 at 18:55
  • 25
    @Rob Truxal. I think the point is that the package is not going to be seen by other users. Maybe you want an older/newer version of a package but if you install it on the system you are going to muck up your work mates. – NDEthos May 18 '17 at 20:17
  • 12
    oh! The `--user` param is about user-isolation! That makes like a rediculous ammt of sense. Thanks @NDEthos! – Rob Truxal May 18 '17 at 20:43
  • would be great if there was a way to configure the environment that the --user is implicit – Martin Kosicky Jun 07 '19 at 06:20
  • 2
    Ok so its like a target environment. What what if the package is install both with and without the --user, then which version will be used? – variable Oct 12 '19 at 07:46
  • @NDEthos : How do we know which `python version` and `pip packages`, we are using, the `/usr/local` ones or `~/.local` ones? Does that depend on `$PATH` variable? Also, using virtualenvironments using `virtualenvwrapper`, accomplishes this task of saving the muck to other users and hiding stuff too, pretty well. – aspiring1 Jan 21 '20 at 07:08
  • Just to be more specific, `~/.local/lib/pythonX.X/site-packages/..` instead of `/usr/local/lib/pythonX.X/site-packages` where X.X is the version – aerijman Apr 04 '20 at 18:43
  • or you want to install a module/package on a system where you do not have root/admin privleges – BrendanSimon Sep 29 '20 at 01:44
  • I have noticed that `--user` is default on my Debian 11 installation. If I want to `pip install` onto the system's location, I'll have to use the `--system` option. I don't know when this behaviour changed, but it's something to take note of. – NostraDavid Feb 05 '23 at 21:22
53

Just a warning:

According to this issue, --user is currently not valid inside a virtual env's pip, since a user location doesn't really make sense for a virtual environment.

So do not use pip install --user some_pkg inside a virtual environment, otherwise, virtual environment's pip will be confused. See this answer for more details.

YaOzI
  • 16,128
  • 9
  • 76
  • 72
40

--user installs in site.USER_SITE.

For my case, it was /Users/.../Library/Python/2.7/bin. So I have added that to my PATH (in ~/.bash_profile file):

export PATH=$PATH:/Users/.../Library/Python/2.7/bin
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Roozbeh Zabihollahi
  • 7,207
  • 45
  • 39
36

Without Virtual Environments

pip <command> --user changes the scope of the current pip command to work on the current user account's local python package install location, rather than the system-wide package install location, which is the default.

This only really matters on a multi-user machine. Anything installed to the system location will be visible to all users, so installing to the user location will keep that package installation separate from other users (they will not see it, and would have to install it themselves separately to use it). Because there can be version conflicts, installing a package with dependencies needed by other packages can cause problems, so it's best not to push all packages a given user uses to the system install location.

  • If it is a single-user machine, there is little or no difference to installing to the --user location. It will be installed to a different folder, that may or may not need to be added to the path, depending on the package and how it's used (many packages install command-line tools that must be on the path to run from a shell).
  • If it is a multi-user machine, --user is preferred to using root/sudo or requiring administrator installation and affecting the Python environment of every user, except in cases of general packages that the administrator wants to make available to all users by default.
    • Note: Per comments, on most Unix/Linux installs it has been pointed out that system installs should use the general package manager, such as apt, rather than pip.

With Virtual Environments

The --user option in an active venv/virtualenv environment will install to the local user python location (same as without a virtual environment).

Packages are installed to the virtual environment by default, but if you use --user it will force it to install outside the virtual environments, in the users python script directory (in Windows, this currently is c:\users\<username>\appdata\roaming\python\python37\scripts for me with Python 3.7).

However, you won't be able to access a system or user install from within virtual environment (even if you used --user while in a virtual environment).

If you install a virtual environment with the --system-site-packages argument, you will have access to the system script folder for python. I believe this included the user python script folder as well, but I'm unsure. However, there may be unintended consequences for this and it is not the intended way to use virtual environments.


Location of the Python System and Local User Install Folders

You can find the location of the user install folder for python with python -m site --user-base. I'm finding conflicting information in Q&A's, the documentation and actually using this command on my PC as to what the defaults are, but they are underneath the user home directory (~ shortcut in *nix, and c:\users\<username> typically for Windows).


Other Details

The --user option is not a valid for every command. For example pip uninstall will find and uninstall packages wherever they were installed (in the user folder, virtual environment folder, etc.) and the --user option is not valid.

Things installed with pip install --user will be installed in a local location that will only be seen by the current user account, and will not require root access (on *nix) or administrator access (on Windows).

The --user option modifies all pip commands that accept it to see/operate on the user install folder, so if you use pip list --user it will only show you packages installed with pip install --user.

Micah Smith
  • 4,203
  • 22
  • 28
LightCC
  • 9,804
  • 5
  • 52
  • 92
  • 3
    Would you consider rephrasing the first part? Outside of a Python virtual environment it really is best to avoid using `pip install` without the `--user` entirely. This would install Python packages in places that really should be left to the system's package manager (for example `apt` in Debian/Ubuntu). It's better not to mess with this, this leads to so many issues. If a Python package needs to be available to all users, then use the operating system's package manager, but do not do `sudo pip install ...`. An alternative is `sudo pip install --target ...`. On Windows it is less of an issue. – sinoroc Oct 30 '19 at 11:37
  • Okay - you mean the second half of the final bullet point in the 'without virtual environments' section? If not, which specific parts? (feel free to edit it directly for this update, I'm not primarily a *nix user) – LightCC Oct 30 '19 at 15:21
  • I see, if you don't use Windows, then it's much less of a concern indeed since it doesn't really have a centralized package manager, unless you start using something like _nuget_. I'll see if I come around to edit your answer. – sinoroc Oct 30 '19 at 15:45
  • @sinoroc I added a Note to that paragraph. Feel free to update it to be more precise, etc., or edit elsewhere if I have similar wording. – LightCC Oct 31 '19 at 15:39
  • I use the `python app` in `windows 10` and `pip install pkg` and `pip install pkg --user` install both in `c:\users\user\appdata\local\packages\pythonsoftwarefoundation.python.3.9_qbz5n2kfra8p0\localcache\local-packages\python39\site-packages`. I wonder why because there is also `C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.1520.0_x64__qbz5n2kfra8p0\Lib\site-packages` that is `non-user`? `python -m site` puts `c:/progr..` in `sys.path` and `c:/users..` in `user_base` and in `sys.path`. So `c:/users..` is both user and non-user? – Timo Jun 20 '21 at 08:23
  • 1
    @Timo If the Python install itself is a user install rather than a system insall, then there might not be a difference in where `--user` installs to. – LightCC Jun 21 '21 at 01:09
  • How about inside a container? For example, install a package via `pip install --user` in a singularity def file? Does it really make a difference? – Parisa Khateri Mar 16 '23 at 08:45
  • @ParisaKhateri Test it out - use `pip list -v` to see where all the currently available packages are installed. Try installing some with `--user` and some without and see where they go. – LightCC May 08 '23 at 14:56
30

Other answers mention site.USER_SITE as where Python packages get placed. If you're looking for binaries, these go in {site.USER_BASE}/bin.

If you want to add this directory to your shell's search path, use:

export PATH="${PATH}:$(python3 -c 'import site; print(site.USER_BASE)')/bin"
rgov
  • 3,516
  • 1
  • 31
  • 51
16

The best way is to install virtualenv and not require the --user confusion. You will get more flexibility and not worry about clobbering the different Python versions and projects every time you pip install a package.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user603749
  • 1,638
  • 2
  • 24
  • 36
10

On macOS, the reason for using the --user flag is to make sure we don't corrupt the libraries the OS relies on. A conservative approach for many macOS users is to avoid installing or updating pip with a command that requires sudo. Thus, this includes installing to /usr/local/bin...

Ref: Installing python for Neovim (https://github.com/zchee/deoplete-jedi/wiki/Setting-up-Python-for-Neovim)

I'm not all clear why installing into /usr/local/bin is a risk on a Mac given the fact that the system only relies on python binaries in /Library/Frameworks/ and /usr/bin. I suspect it's because as noted above, installing into /usr/local/bin requires sudo which opens the door to making a costly mistake with the system libraries. Thus, installing into ~/.local/bin is a sure fire way to avoid this risk.

Ref: Using python on a Mac (https://docs.python.org/2/using/mac.html)

Finally, to the degree there is a benefit of installing packages into the /usr/local/bin, I wonder if it makes sense to change the owner of the directory from root to user? This would avoid having to use sudo while still protecting against making system-dependent changes.* Is this a security default a relic of how Unix systems were more often used in the past (as servers)? Or at minimum, just a good way to go for Mac users not hosting a server?

*Note: Mac's System Integrity Protection (SIP) feature also seems to protect the user from changing the system-dependent libraries.

- E

rgov
  • 3,516
  • 1
  • 31
  • 51
Edmund's Echo
  • 766
  • 8
  • 15
1

Why would intalling the package to ~/.local/ matter? Why not just put an executable somewhere in my $PATH?

~/.local/bin directory is theoretically expected to be in your $PATH.

According to these people it's a bug not adding it in the $PATH when using systemd.

This answer explains it more extensively.

But even if your distro includes the ~/.local/bin directory to the $PATH, it might be in the following form (inside ~/.profile):

if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

which would require you to logout and login again, the first time the directory is created.

Jannis Ioannou
  • 1,692
  • 1
  • 14
  • 17
  • 1
    Is the best practice to place `~/.local/bin` in the PATH before system dirs like `/bin` and `/usr/bin` or after the system dirs? If the local bin is earlier in the path then a user could end up being spoofed by replacements for commands that take a password such as passwd, ssh, scp, etc. – E Gow Feb 25 '21 at 21:29
  • Shouldn't be your decision. My .profile puts this directory at the head of the path if it exists. It means that anything I personally install has precedence over standard installs which is right. – Francis Cagney May 15 '22 at 10:58
0

If you are using your own Conda environment, don't use --user. And if you are using a public Conda environment, use --user to install packages at your home ~/.local/lib/.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131