pip installs packages into the site-packages directory of whichever Python interpreter it is associated with. The exact path depends on three things: the operating system, whether you are inside a virtual environment, and whether you used the --user flag. The most reliable way to find the actual path is to ask Python directly with python -m site rather than memorizing OS-specific conventions.

The Core Rule

Every Python interpreter has a site-packages directory where third-party packages are installed. When you run pip install requests, pip places the package files into the site-packages for the Python interpreter that pip belongs to.

The most common source of confusion is running pip tied to one interpreter while running your code with a different interpreter. That is why the recommended invocation is:

# Always use this form to guarantee pip matches your interpreter
python -m pip install requests

This ensures the pip you invoke is the one bundled with the exact python binary you are calling.

Finding the Actual Install Location

Method 1: python -m site

This prints all site-packages directories for the current interpreter:

python -m site

Output includes sys.path, user site-packages, and global site-packages directories.

Method 2: Scripted Query

For a precise, parseable answer:

1import site
2import sys
3
4print("Interpreter:", sys.executable)
5print("User site-packages:", site.getusersitepackages())
6for path in site.getsitepackages():
7    print("Global site-packages:", path)

Method 3: pip show for a Specific Package

If you want to know where a specific package was installed:

python -m pip show requests

The Location: field in the output tells you the directory. You can also check from within Python:

import requests
print(requests.__file__)
# e.g., /usr/lib/python3.11/site-packages/requests/__init__.py

Install Locations by Context

These paths vary by distribution and Python build, so always verify with python -m site rather than hard-coding paths.

Virtual Environments

When a virtual environment is activated, pip installs into that environment's own site-packages, completely isolated from the system Python.

1# Create and activate a virtual environment
2python3 -m venv .venv
3source .venv/bin/activate      # Linux/macOS
4# .venv\Scripts\activate       # Windows
5
6# Verify pip points to the venv
7python -m pip --version
8# pip 23.x from .venv/lib/python3.11/site-packages/pip (python 3.11)
9
10# Install a package
11python -m pip install requests
12
13# Confirm its location
14python -m pip show requests
15# Location: /home/user/project/.venv/lib/python3.11/site-packages

Deactivating the environment reverts python and pip to the system versions. Packages installed inside the venv are not visible outside it, and vice versa.

The --user Flag

When you do not have write access to the global site-packages (common on shared servers or when the system Python is managed by the OS package manager), --user installs to a per-user directory:

python -m pip install --user requests

The user site-packages path is typically ~/.local/lib/python3.X/site-packages on Linux/macOS. You can query it with:

python -m site --user-site

Note that --user and virtual environments are mutually exclusive. If you are inside a venv, --user is ignored (or raises an error, depending on the pip version).

Packages vs. Scripts: Two Different Locations

When pip installs a package that includes command-line tools (like black, flask, or pytest), it installs two things in two places:

python -m pip install black

This is why you can sometimes import a package successfully but get "command not found" when trying to run its CLI tool. The bin/ or Scripts/ directory may not be on your PATH.

1# Find where scripts are installed
2python -m pip show --verbose black | grep -i "location\|scripts"
3
4# Or check directly
5which black               # Linux/macOS
6where black               # Windows

Diagnosing "Module Not Found" After Installation

If pip install succeeds but import fails, you almost certainly have a Python interpreter mismatch. Run this diagnostic:

1# Check which pip you used
2python -m pip --version
3
4# Check which python you are running
5python --version
6which python     # Linux/macOS
7where python     # Windows
8
9# Compare: if these point to different interpreters, that's your problem
10python -c "import sys; print(sys.executable)"

If pip belongs to Python 3.9 but you are running Python 3.11, the package is installed in the wrong site-packages. Always use python -m pip to avoid this.

Common Pitfalls

• Using a bare pip command that belongs to a different interpreter than the python you are running. Always use python -m pip install to keep them aligned.
• Installing packages globally on a system where the OS manages its own Python packages (e.g., Debian/Ubuntu). This can break OS tools. Use a virtual environment or --user instead.
• Assuming pip list shows packages available to your current interpreter. If multiple Python installations exist, pip list only shows packages for the interpreter it is tied to. Verify with python -m pip list.
• Using --user inside a virtual environment. The --user flag either gets ignored or raises an error, depending on the pip version. Inside a venv, just use pip install without flags.
• Forgetting that site-packages for scripts (bin/) is a different directory than site-packages for Python modules. A successful import does not guarantee the CLI tool is on your PATH.

Summary

• pip installs into the site-packages directory of its associated Python interpreter. Use python -m pip to guarantee the right one.
• The exact path depends on the OS, whether you are in a virtual environment, and whether you used --user.
• Use python -m site to discover all site-packages directories and python -m pip show package_name to find where a specific package was installed.
• Virtual environments are the recommended approach for project dependencies because they provide complete isolation.
• CLI scripts and Python packages install to different directories. A successful import does not mean the command-line tool is on your PATH.