How to Fix: pip error: externally-managed-environment

Quick Fix

Fastest fix: create and use a virtual environment instead of installing system-wide:

1. Run: python3 -m venv ~/venv
2. Activate it: source ~/venv/bin/activate (Linux/Mac) or ~/venvScriptsactivate (Windows)
3. Install normally: pip install your-package-name

If you just want the old behavior back for a one-off script, add –break-system-packages to your pip command instead, but understand this can break your OS’s Python tools.

Step-by-Step Guide

What this error means

Starting with Python 3.11+ on distros like Debian 12 ‘Bookworm’, Ubuntu 23.04+, Fedora 38+, and Homebrew-managed Python on macOS, your system now follows a rule called PEP 668. It proposes a way for distributors of a Python interpreter to mark that interpreter as having its packages managed by means external to Python, such that Python-specific tools like pip should not change the installed packages in the interpreter’s global sys.path in any way unless specifically overridden.

In plain terms: your Python environment is managed by the operating system or a package manager, and direct installation using pip is restricted. You don’t want a stray pip install breaking your operating system packages, that’s the source of the error: you’re trying to pip install into an environment managed by the Linux distribution.

You’ll know it’s this exact issue if you see a message like: error: externally-managed-environment × This environment is externally managed, often followed by a suggestion to use apt, brew, a venv, or pipx.

Fix 1: Use a virtual environment (recommended for most people)

This is the safest, most universally recommended fix and works the same way on Linux, macOS, and Windows.

1. Create the environment. Run python3 -m venv path/to/venv (use any folder name/path you like, e.g. ~/myproject/venv).
2. Activate it. On Linux/Mac run source path/to/venv/bin/activate. On Windows run pathtovenvScriptsactivate.
3. Install your package. Now run pip install package-name as normal — it installs only inside the venv, so it can’t conflict with system packages.
4. Remember to reactivate the venv every time you open a new terminal session to work on that project, since once deactivated, the packages you installed are no longer accessible in your environment, but you can access them again by reactivating the same virtual environment.

On Debian/Ubuntu, if venv creation fails, install the full Python package first: make sure you have python3-full installed.

Fix 2: Install via your system’s package manager

If you just need a common library and don’t want a venv, install it through the OS instead of pip.

1. On Debian/Ubuntu: search for the package name first, since the name of the system package may be different than the one that pip uses — typically Python packages are named python3-<package> in Ubuntu. Then run sudo apt install python3-packagename.
2. On macOS with Homebrew: the error itself suggests this — to install Python packages system-wide, try brew install xyz, where xyz is the package you are trying to install.
3. Trade-off to know: the system package manager may lag behind pip’s latest release, since the version installed with pip is often more up-to-date than the one installed with apt, because the system package manager usually holds back packages while pip installs the latest version.

Fix 3: Use pipx for standalone command-line tools

If you’re installing a Python application (a CLI tool) rather than a library for your own code, pipx is the recommended official approach.

1. Install pipx via your package manager, e.g. brew install pipx or sudo apt install pipx.
2. Install the tool with pipx install xyz instead of pip. For Python-based applications that can be used globally, the error message may recommend pipx — it automatically handles virtual environments for you, allowing you to run the application globally without interfering with the system-wide Python environment.

Fix 4: Force the install with –break-system-packages (use with caution)

This overrides the protection and restores old pip behavior. It’s the fastest option but carries real risk.

1. Run the install with the flag: pip install package-name –break-system-packages (or python -m pip install package-name –break-system-packages).
2. To make it permanent (not recommended for most users) run python3 -m pip config set global.break-system-packages true.
3. Understand the risk: this parameter forces pip to install packages directly into the system environment, which is faster but carries the risk of causing version conflicts with OS-level software. If you use it on Homebrew’s Python, also pass –user as recommended, since if you disable this error, it’s strongly recommended to additionally pass the –user flag to pip, or set user = true in pip.conf, because failure to do this can result in a broken Homebrew installation.

Advanced: delete the EXTERNALLY-MANAGED marker file

The restriction is enforced by a single marker file, and some advanced users just remove it, though this is the most aggressive option.

1. Locate it in your Python’s stdlib directory, e.g. /usr/lib/python3.11/EXTERNALLY-MANAGED — this error arises when pip installs outside of a virtual environment and a marker file, EXTERNALLY-MANAGED, exists in Python’s stdlib directory, usually located in /usr/lib/<python_version>.
2. Delete it with sudo rm /usr/lib/python3.xx/EXTERNALLY-MANAGED. After this, now you should be able to install packages seamlessly with pip or pip3.
3. Note: this is a system-wide, permanent change until the file is recreated (e.g. on the next OS update), and it removes the safety net entirely — prefer the venv or pipx approaches unless you fully understand the trade-off.

If you’re inside Docker

Inside containers the same error can appear even though isolation is already handled at the container level. Three options work well here: add –break-system-packages to your Dockerfile’s pip install line (safe since containers are disposable), delete the EXTERNALLY-MANAGED file in the image, or switch your base image to a slim variant, since images like python:3.12-slim don’t include the externally managed marker at all, so the error never appears — if you’re starting a new project, this is often the simplest path.

When to get further help

If none of these fixes work, or you get a different underlying error after applying one of them (e.g. permission errors, missing python3-venv module, or a broken Homebrew install), the issue is likely specific to your OS setup or a corrupted Python install. In that case check your distribution’s official documentation or package manager support channels, or consider reinstalling Python cleanly for your platform.