01
Check which Python and pip you are actually using
Start with the executable paths and versions. A terminal can have several Python installations, while a bare pip command belongs to only one of them. Using python3 -m pip ties the installer invocation to the selected interpreter and makes the comparison clearer.
Check whether that interpreter is already inside a virtual environment. The prefix comparison below is useful for standard venv environments. Record the values locally; sharing full filesystem paths can expose usernames or project locations that are irrelevant to a public issue.
python3 --version
python3 -m pip --version
python3 -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix)"02
Understand what the externally managed marker protects
The Python packaging specification allows a distributor to mark a base environment as externally managed. Package installers then avoid changing it in situations covered by that policy. Installing a project dependency directly into the operating system’s Python can conflict with packages maintained by the system’s own tools.
Do not start by deleting the marker, using sudo, or adding an override just to get past the message. Those actions change the ownership boundary instead of giving the project an appropriate dependency environment. A project virtual environment usually addresses the actual requirement more directly.
03
Create a project environment with the intended interpreter
Choose the Python version your project supports, then create a virtual environment in the project directory. This produces a separate package-install location while retaining a relationship to the selected base interpreter. It does not install a different Python version for you.
The following commands use explicit executable paths, so activation is optional. They assume a POSIX shell and a requirements.txt file maintained by the project. On Windows, the environment’s executable directory is Scripts rather than bin.
python3 -m venv .venv
.venv/bin/python -m pip --version
.venv/bin/python -m pip install -r requirements.txt04
Point execution and tooling at the same environment
Installing into .venv does not automatically change an IDE, a service unit, or a separate terminal’s interpreter. Configure those tools to run the project with the same environment. Otherwise installation can succeed while the program still reports ModuleNotFoundError elsewhere.
Activation is a shell convenience that adjusts command lookup; it is not required when using .venv/bin/python explicitly. For automation, that explicit path makes the dependency environment visible in the command rather than depending on prior interactive shell state.
05
Verify the interpreter and the installed dependency set
Run a small interpreter check, inspect pip’s location, and run pip check for installed dependency conflicts. The prefix assertion should pass in a standard venv. Then execute the project’s own test or startup command with that interpreter; pip check cannot establish that application behavior is correct.
If creating the environment itself fails, read that error separately. Some operating-system installations provide venv support through an additional distribution package. Follow the distributor’s instructions for that component instead of modifying the system environment to bypass the original pip policy.
.venv/bin/python -c "import sys; assert sys.prefix != sys.base_prefix; print(sys.executable)"
.venv/bin/python -m pip --version
.venv/bin/python -m pip check
# Run your project's tests with .venv/bin/python as well.06
Recreate environments rather than shipping them between machines
Keep the dependency declaration in version control and exclude the generated .venv directory. Virtual environments contain interpreter paths and platform-specific details; copying one between machines is not a reliable deployment strategy. Recreate it using the target interpreter and the project’s dependency process.
For an end-user command-line application, a dedicated application installer or the operating system’s package manager may be more appropriate than a project venv. The decision depends on whether you are developing a project or installing a standalone tool. Neither case requires treating every system-managed Python as a general-purpose project install target.
Know the limits
The commands target standard Python venv on POSIX systems. Conda, containers, Windows paths, distribution packages, and standalone CLI installers have their own workflows. A venv isolates Python packages; it is not an operating-system security sandbox.
Sources & further reading
A technical publication by CoreTrailKit.
Browse all articles