The externally-managed-environment error means your operating system has marked its Python as managed by its own package manager, so pip refuses to change it. The safe fix is to install into a virtual environment, or use pipx for command-line tools, instead of forcing the install.
What the error is
PEP 668 lets a Python distributor place a marker file named EXTERNALLY-MANAGED in the interpreter's standard library directory. When an installer sees that file and you are not inside a virtual environment, it stops and prints a message. The distributor can supply the wording; otherwise pip shows a built-in message that points to virtual environments.
The reason is practical. Linux distributions ship tools written in Python. If you run a pip install or uninstall against that same interpreter, you can overwrite or remove files the OS package manager owns, and something unrelated can stop working.
The three fixes, in order of preference
- Create a virtual environment for the project: run python -m venv, activate it, and install there. The PEP says Python specific tools should be used only inside one.
- Use pipx if you want a command-line application and are not writing Python yourself. It creates an isolated environment for that one application.
- Use the OS package if your distribution already packages the library, and you only need it for system scripts.
What about breaking system packages
The PEP names an override flag called break system packages. It says the flag should not be on by default and should carry a sense that using it is risky. Treat it as a last resort for a throwaway container, not for a laptop or a server you care about.
Note also what the marker is not. The PEP states that the restriction exists to discourage accidental changes, not to enforce security. It will not stop a determined or malicious install. It only stops you hurting your own system by mistake.
Why this matters for supply chain security
A global install is hard to audit. Packages from months of unrelated experiments pile up in one place, with unknown versions and unknown owners. A virtual environment per project is small, can be deleted and rebuilt from a requirements file, and makes it obvious what the project depends on. That makes scanning and review simpler. See do you need a virtual environment for security for the limits of that isolation.
Quick check
Is sudo pip install a good workaround?
No. Running pip as an administrator against the system interpreter is exactly the change the marker is meant to prevent.
Does the error mean my Python is insecure?
No. It means your distribution manages that interpreter's packages. It is a safeguard against accidental breakage.
Safeguard's dependency scanning reads a project's declared and resolved packages, so a clean per project environment gives it a clear list to check. A free scan is available.
Sources
Last reviewed: 19 October 2026.
