Error database

error: externally-managed-environment (pip)

Your OS protects its system Python from pip installs. Create a virtual environment for your project — that is the intended fix, not an obstacle to bypass.

The message you saw
error: externally-managed-environment (pip)

By Updated

The error

Output
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you.

note: If you believe this is a mistake, please change your python3 command to use a virtual environment or a wheel-based install.
hint: See PEP 668 for the technical details.

What it means

Your operating system's Python is not yours alone — system tools depend on it. Historically, pip install into it could silently break those tools, and sudo pip install could break the OS itself. PEP 668 lets distributions mark their Python as externally managed: pip now refuses to write into it. Debian 12, Ubuntu 23.04+, recent Fedora and Homebrew Python all do this. Nothing is broken; a guardrail is working.

Why it happens

You ran pip install something (or pip3, or sudo pip) against the system interpreter instead of a project environment. On a fresh machine, before the first venv exists, that is the natural first move — which is why this error greets so many people on day one.

How to fix it

1. Create and use a virtual environment — the intended path.

bash
cd ~/projects/my-ai-project
python3 -m venv .venv
source .venv/bin/activate
python -m pip install torch pandas

The prompt gains a (.venv) prefix; installs now land in the project, isolated and disposable. Each project gets its own. This also fixes the follow-on confusion of packages "installing but not importing" — see the module-not-found page.

2. For standalone command-line tools, use pipx.

bash
sudo apt install pipx
pipx install ruff

pipx builds a private environment per tool and puts the command on your PATH — the right home for tools you run rather than import.

3. For OS-level needs, use the OS package manager. sudo apt install python3-requests installs Debian's own build, integrated with system updates. Rarely what an AI project wants, but it is what the message's first suggestion is for.

4. --break-system-packages does what it says. It exists for containers and images where the system Python is the project Python. On a workstation it can wreck apt and your desktop tools. If you use it in a Dockerfile, that is defensible; in a terminal on your laptop, prefer fix 1.

How to prevent it

Adopt the venv habit universally: one environment per project, activated before any pip command, captured in requirements.txt. Never sudo pip anywhere. The guardrail then never fires, because you never aim at the system Python.