Use a virtual environment for project work and keep the user option for rare, deliberate cases. The pip documentation describes the user install as a per-account location shared by every project you run. A virtual environment isolates one project, so a bad or conflicting package stays contained and can be deleted.
What the user option does
The pip user guide explains that some Python distributions support an install location specific to a user. Passing the user option to pip install turns that mode on. The location comes from Python's site.USER_BASE value, and you can move it by setting the PYTHONUSERBASE environment variable.
The guide lists rules for how it interacts with the rest of the system. For example, if a globally installed package conflicts with your requirement, the global one is ignored and not uninstalled. If a global package already satisfies the requirement, pip does nothing and reports it as satisfied.
The effect is that user installs sit between the system and a project. They avoid needing root, but they are still shared by everything you run as that account.
Side by side
| Question | User install | Virtual environment |
|---|---|---|
| Where does it go? | One folder for your account | A folder inside or next to the project |
| Who sees it? | Every Python program you run | Only that environment |
| Easy to wipe? | Not really, packages mix over time | Delete the folder and start over |
| Needs root? | No | No |
| Good for | Occasional personal command line tools | Almost all project dependencies |
Why isolation is the safer default
Think about an incident where a package turns out to be malicious. With a project environment, you delete one folder, rotate the credentials that process could reach, and rebuild from a lockfile. With a user install, the package has been on the path of every script you ran as that account. Working out what it touched is harder.
Isolation also keeps versions honest. Two projects that need different versions of one library cannot both be satisfied by a single shared folder.
A practical routine
- Create an environment per project and activate it.
- Confirm the interpreter path is inside the environment. Our post on which pip you are running shows the check.
- Install from a pinned requirements file. For repeatability, see hash checking in Dockerfiles.
- For standalone command line tools, use an isolated tool installer instead of the user folder. The pipx or pip post covers it.
- If you must use the user option, list what is there from time to time and remove what you do not use.
What about the operating system's own Python?
Some systems mark their Python as externally managed and make pip refuse by default. That guard exists so you do not break system tools. The sensible response is an environment, not a flag that overrides the guard.
Quick check
Does the user option need root?
No, which is why it is popular, but it still shares one folder across everything you run.
Can I move the user install folder?
Yes. The pip guide says setting PYTHONUSERBASE changes site.USER_BASE.
Sources
Last reviewed: 19 October 2026.
