Fix pip "externally-managed-environment" Error on Ubuntu and Debian

You try to install a Python package with pip, but instead of downloading it, pip stops with an externally-managed-environment error. Running the command with sudo does not solve it. The restriction protects the Python installation managed by your Linux distribution.

For project libraries, the fix is to create a virtual environment and install the package there. For command-line applications, use pipx. This guide walks through both approaches on Ubuntu and Debian, explains when to use apt, and covers the checks to make if the error persists.

Fixing the Error with a Virtual Environment #

If you are installing a library for a script or application, such as requests, use a virtual environment . It gives the project its own packages without changing the ones used by the operating system.

First, install Python’s venv support from the distribution repositories:

sudo apt update
sudo apt install python3-venv

Open your project directory. If you are following along without an existing project, create a directory for the example:

mkdir -p ~/python-demo
cd ~/python-demo

Create a virtual environment named .venv, activate it, and install the package:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install requests

Replace requests with the package you originally tried to install. After activation, python points to the virtual environment’s interpreter, and python -m pip uses the pip that belongs to it. You do not need sudo for the installation.

Check that the package can be imported:

python -c "import requests; print(requests.__name__)"

The command prints:

requests

This confirms that the Python interpreter you are using can load the package. Run your project with the same interpreter, either while the environment is active or by using .venv/bin/python directly.

For an existing project with a requirements.txt file, install its dependencies from the project directory instead:

python -m pip install -r requirements.txt

When you finish working in the environment, leave it with:

deactivate

The packages remain in .venv. Activate the environment again when you return to the project. On Python 3.13 and later, which ships with Ubuntu 26.04 and Debian 13, venv writes a .gitignore file inside .venv, so Git skips the environment automatically. On older releases such as Ubuntu 24.04, add .venv/ to your project’s .gitignore. The environment can be recreated from your dependency file.

Installing Command-Line Applications with pipx #

If you want to install a command rather than import a library in your code, pipx is usually a better fit. It creates a separate virtual environment for each application and makes its commands available to your user account.

On Ubuntu and Debian, install pipx with apt, then add its executable directory to your PATH:

sudo apt update
sudo apt install pipx
pipx ensurepath

On Ubuntu 26.04, the pipx package recommends MkDocs, so apt also installs dozens of extra packages such as MkDocs and NumPy. pipx works without them. To skip them, add --no-install-recommends to the apt install command.

Close and reopen your terminal so it picks up the PATH change. Then install a Python command-line application. For example, to install HTTPie:

pipx install httpie

Verify that its command is available:

http --version

The command prints the installed HTTPie version. Unlike a project environment, you do not need to activate anything before using http.

Do not use pipx install requests to make requests available to your scripts. pipx stops with No apps associated with package requests because the package provides no commands. Libraries belong in the environment where your code runs. The pipx documentation covers managing and upgrading the applications you install this way.

Installing Distribution Packages with apt #

When you need a Python package for the distribution’s system interpreter, check whether it is available through apt. For example, install the distribution’s Requests package with:

sudo apt install python3-requests

Notice that the apt package is named python3-requests, while its PyPI name is requests. Package names do not always map directly between the two repositories.

This installation is managed by apt and is available to the system Python. A normal virtual environment does not include system packages, so you still need to install requests inside .venv if that is where your project runs.

For project dependencies, keep using the virtual environment, especially when the project needs a version different from the one your distribution provides.

Using uv Instead of pip #

If you already use uv , you can create the environment and install the library with its pip-compatible interface:

uv venv .venv
uv pip install --python .venv/bin/python requests

The explicit interpreter path directs the installation into .venv. You can run code with .venv/bin/python or activate the environment in the usual way. You do not need to install pip into the environment for uv pip install to work.

For a command-line application, use uv’s tool interface instead:

uv tool install httpie

Like pipx, this installs the application in its own environment. If you already installed HTTPie with pipx, uv stops with an Executables already exist error because it does not overwrite commands from another tool. Remove the pipx copy with pipx uninstall httpie, then run the command again.

If uv reports that the executable directory is missing from your PATH, run the following command and reopen your terminal:

uv tool update-shell

Why pip Reports an Externally Managed Environment #

The error usually appears when pip tries to install into a distribution-managed Python installation outside a virtual environment. The beginning of the message looks like this:

error: externally-managed-environment

× This environment is externally managed

The rest of the message depends on your distribution and may suggest an apt package, a virtual environment, or pipx.

Ubuntu 24.04 and 26.04, and Debian 12 and 13, mark their system Python as externally managed. This follows the packaging rules introduced by PEP 668 . An EXTERNALLY-MANAGED marker tells tools such as pip that another package manager is responsible for that installation.

The distinction matters because system tools can depend on particular Python packages. A package installed through pip can shadow a distribution package with an incompatible version, even if pip does not overwrite its files. The restriction prevents those two package managers from making conflicting changes to the same Python environment. Our pip vs apt guide explains how their package sources and installation paths differ.

This is not a permissions error or a sign that pip needs upgrading. Reinstalling pip does not remove the underlying restriction.

Why –user and sudo Do Not Fix It #

Older instructions often recommend pip install --user when a regular install fails. That changes the installation directory, but it does not isolate the packages from the system interpreter. User packages can still shadow distribution packages, so pip rejects pip install --user with the same error.

Running pip with sudo changes the account that runs it, but the system Python is still marked as externally managed. sudo pip install fails with the same error, and it is unnecessary inside a virtual environment.

You may also see the --break-system-packages option suggested as a fix. It explicitly allows pip to modify an externally managed installation. It does not create an isolated environment or resolve package conflicts. The upstream specification treats overriding the restriction as a risky operation.

For the same reason, do not delete the EXTERNALLY-MANAGED marker or make the override permanent with break-system-packages = true in pip.conf or the PIP_BREAK_SYSTEM_PACKAGES environment variable. Use a virtual environment, pipx, or the distribution package manager according to what you are installing.

Troubleshooting #

Creating the environment fails because ensurepip is unavailable
Without the venv package, python3 -m venv stops with The virtual environment was not created successfully because ensurepip is not available. Install python3-venv with apt, then rerun python3 -m venv .venv in the same directory. The message may name a versioned package such as python3.14-venv. The generic python3-venv package installs it for the distribution’s default Python version. If you selected a different interpreter, such as python3.12, you need the matching venv package from the same package source, where one is provided.

The error persists after activating .venv
You may still be calling a system pip through an alias, an absolute path, or a command that uses sudo. From the project directory, target the environment directly:

.venv/bin/python -m pip install requests

This avoids relying on shell activation or the meaning of the pip command. To see which interpreter a plain python command selects, run:

python -c "import sys; print(sys.executable); print(sys.prefix != sys.base_prefix)"

For an active virtual environment, the output should show the path to its Python executable followed by True. A False result means that interpreter is running outside a virtual environment. If the shell prints python: command not found, no environment is active. Ubuntu and Debian do not install a plain python command by default.

The script still reports No module named requests
The package may be installed in .venv while your script runs with the system interpreter. From the project directory, run .venv/bin/python your_script.py, replacing your_script.py with your script’s name. Configure your editor or service to use that interpreter too.

The command installed by pipx is not found
Run pipx ensurepath and reopen your terminal. pipx list shows the installed applications and their exposed commands. The command name can differ from the package name: the httpie package, for example, provides the http command.

Conclusion #

For a scheduled job or systemd service, use the full path to your project’s .venv/bin/python instead of relying on an activated shell. The pip cheatsheet covers installing, pinning, and inspecting packages once you are working inside the right environment.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page