PEP 668 and Python CLIs: the externally-managed-environment Error

Run pip install mytool with the system Python on a recent Debian or Ubuntu release, or with Homebrew's Python on macOS, and you meet this:

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.

It is not a bug and not a permissions problem. It is PEP 668 working as designed: the operating system declares that its Python belongs to the package manager, and pip refuses to install into it. For people installing CLIs, the fix is to use the tools built for that job. For people writing CLIs, PEP 668 changes what your installation instructions should say, and it affects any feature that installs packages at runtime, such as plugin installers. This guide explains the mechanism and covers both sides. It belongs to the virtual environments topic.

Prerequisites

• A Linux distribution or macOS Python that ships an EXTERNALLY-MANAGED marker (most current ones do).
• pipx or uv for the recommended installation paths.

How the marker works

PEP 668 defines a file named EXTERNALLY-MANAGED in the interpreter's standard library directory. When pip (version 23 and later) sees it, it refuses to install into that interpreter's site-packages and prints the message the file contains — which is why the advice mentions apt on Debian and brew on Homebrew.

python3 -c "import sysconfig; print(sysconfig.get_path('stdlib'))"
# /usr/lib/python3.14
ls /usr/lib/python3.14/EXTERNALLY-MANAGED

The reason is practical. On these systems, the package manager installs Python packages that system tools depend on — apt itself on some distributions, desktop utilities, the distribution's own scripts. A sudo pip install --upgrade that replaces one of those packages with an incompatible version can break the operating system in ways that are hard to diagnose. Even pip install --user, which writes to your home directory, shadows system packages for every program that user runs. The marker turns those silent breakages into an explicit error.

Crucially, the marker only applies to the system interpreter. Inside a virtual environment, sys.prefix differs from sys.base_prefix, and pip installs freely — which is the whole point of the recommended fixes.

The recipe: installing a CLI

For a command-line tool you want on your PATH, use an installer that creates an isolated environment per tool:

pipx install mytool              # one venv per tool, executables linked onto PATH
uv tool install mytool           # the same idea, faster
uvx mytool --help                # run without installing, from a cached environment

Both pipx and uv install the tool into its own virtual environment, so the marker does not apply, the tool's dependencies cannot conflict with system packages or with other tools, and uninstalling removes everything. Installing and distributing CLIs with pipx and uv tool install vs pipx cover the details. On a fresh Debian or Ubuntu system, sudo apt install pipx installs pipx itself through the package manager — the one Python tool that legitimately comes from the system.

For working on a project, create a project environment: uv sync, or python3 -m venv .venv && .venv/bin/pip install -e .. Debian-based systems may need python3-venv (or python3-full) installed for python3 -m venv to work.

What about --break-system-packages?

pip offers an override, --break-system-packages (or PIP_BREAK_SYSTEM_PACKAGES=1). The name is honest. It is appropriate in exactly one kind of place: a disposable environment where the system Python serves no other purpose, such as a single-purpose container built from a distribution image. Official python: Docker images do not ship the marker at all, because their Python is not managed by a system package manager. On a workstation or server, the override trades a clear error now for a mysterious failure later.

What CLI authors should change

Installation instructions

Lead with the isolated installers and drop bare pip install from the first line of your README:

## Install

    pipx install mytool        # or: uv tool install mytool

Try it without installing: `uvx mytool --help`.

Mention pip install mytool only in the context of an existing virtual environment ("to use mytool as a library in your project…"). Users who copy the first command they see should get a command that works on every modern system.

Runtime package installation

Some CLIs install packages themselves — a mytool plugin install NAME command, an "install the optional dependency now?" prompt. Under PEP 668 those features break if the CLI runs from a system interpreter, and they are risky even in a tool environment managed by pipx or uv, where installing behind the manager's back confuses its records. Detect the situation and delegate:

# src/mytool/plugins.py
from __future__ import annotations

import sys
import sysconfig
from pathlib import Path


def externally_managed() -> bool:
    """True if pip would refuse to install into this interpreter (PEP 668)."""
    in_venv = sys.prefix != sys.base_prefix
    marker = Path(sysconfig.get_path("stdlib")) / "EXTERNALLY-MANAGED"
    return not in_venv and marker.exists()


def install_hint(package: str) -> str:
    prefix = Path(sys.prefix)
    if (prefix / "pipx_metadata.json").exists():
        return f"pipx inject mytool {package}"
    if (prefix / "uv-receipt.toml").exists():
        return f"uv tool install mytool --with {package} --force"
    if externally_managed():
        return f"install mytool with pipx or uv tool, then add {package} the same way"
    return f"{sys.executable} -m pip install {package}"

The installer fingerprints — pipx_metadata.json and uv-receipt.toml — are the same ones used in self-upgrading a CLI installed with pipx or uv. Printing the right command is almost always better than running pip yourself.

UX considerations

• Never suggest sudo pip. It is the command PEP 668 exists to stop, and it still appears in old READMEs and Stack Overflow answers users will find.
• Explain the error in your docs. A short "Seeing externally-managed-environment?" entry in your troubleshooting section saves many issue reports.
• Test the install path you document. A CI job that runs pipx install of the built wheel on a distribution image with the marker catches instructions that only work on your laptop.
• Do not detect and bypass. Silently adding --break-system-packages in a plugin installer turns your tool into the cause of someone's broken system.

Testing the behaviour

The detection logic is easy to test by faking the interpreter layout:

# tests/test_plugins.py
import sys

from mytool import plugins


def test_venv_is_never_externally_managed(monkeypatch, tmp_path):
    monkeypatch.setattr(sys, "prefix", str(tmp_path / "venv"))
    monkeypatch.setattr(sys, "base_prefix", str(tmp_path / "base"))
    assert plugins.externally_managed() is False


def test_marker_on_system_python(monkeypatch, tmp_path):
    stdlib = tmp_path / "lib" / "python3.13"
    stdlib.mkdir(parents=True)
    (stdlib / "EXTERNALLY-MANAGED").write_text("[externally-managed]\n")
    monkeypatch.setattr(sys, "prefix", str(tmp_path))
    monkeypatch.setattr(sys, "base_prefix", str(tmp_path))
    monkeypatch.setattr(plugins.sysconfig, "get_path", lambda name: str(stdlib))
    assert plugins.externally_managed() is True
    assert "pipx or uv tool" in plugins.install_hint("mytool-aws")


def test_pipx_environment_gets_inject_hint(monkeypatch, tmp_path):
    (tmp_path / "pipx_metadata.json").write_text("{}")
    monkeypatch.setattr(sys, "prefix", str(tmp_path))
    assert plugins.install_hint("mytool-aws") == "pipx inject mytool mytool-aws"

For the end-to-end view, run your documented install commands in a debian:stable or ubuntu:latest container in CI — the system Python there carries the marker, so a README that still says pip install mytool fails exactly as it would for users.

Conclusion

The externally-managed-environment error is the operating system protecting its own Python. Install CLIs with pipx or uv tool install, develop in project virtual environments, and reserve --break-system-packages for disposable containers. As a CLI author, put the isolated installers first in your instructions, test them on a system that has the marker, and make any runtime installation feature detect its environment and print the right command instead of fighting PEP 668.

Frequently asked questions

Related

• Up: Virtual environments and isolation best practices
• Isolating CLI tools from project dependencies
• Debugging wrong-Python and wrong-venv problems
• Installing and distributing CLIs with pipx
• uv tool install vs pipx for CLIs