Introduction

When Python 2 and Python 3 both exist on the same machine, the safest rule is to invoke pip through the interpreter you actually want. Instead of relying on whichever pip happens to be first on PATH, run python3 -m pip for Python 3 and python2 -m pip for Python 2.

Use the Interpreter to Select the Right pip

This is the reliable pattern:

python3 -m pip install requests
python2 -m pip install requests

The -m pip form removes ambiguity because the interpreter itself decides which pip module runs.

Avoid Bare pip When Multiple Versions Exist

If both versions are installed, a bare command such as:

pip install requests

can point at the wrong interpreter. That may install a package successfully and still leave your actual runtime unable to import it.

In mixed-version environments, ambiguity is the enemy. Be explicit every time.

Verify Which Interpreter Owns the Package

After installation, verify the environment directly:

python3 -m pip --version
python2 -m pip --version

The output shows which Python executable the pip installation belongs to. This is one of the fastest ways to catch environment confusion.

Prefer Virtual Environments for Real Projects

Even if Python 2 and Python 3 must coexist on the machine, individual projects should still use isolated environments where possible. That keeps dependencies from bleeding across unrelated work.

For Python 3, for example:

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

Inside the virtual environment, python and pip refer to that environment's interpreter and packages.

Understand the Practical Goal

The real goal is not “make one global pip command smart enough.” The goal is “install packages into the interpreter environment that will actually run the code.” Once you adopt that mindset, pythonX -m pip becomes the natural habit.

Virtual Environments Make Version Boundaries Obvious

A virtual environment gives each project its own interpreter and package directory, which is much easier to reason about than mixing global installs. Even on systems that still carry Python 2, project work should usually happen inside isolated Python 3 environments.

PATH Problems Are Usually a Symptom

If pip, python, and imports do not line up, the real issue is usually environment selection, not package installation itself. Use explicit interpreter commands to remove guesswork before changing PATH settings repeatedly.

Common Pitfalls

• Using a bare pip command and assuming it targets Python 3.
• Installing a package successfully but into the wrong interpreter environment.
• Forgetting to check pythonX -m pip --version when debugging import failures.
• Treating global installs as harmless when a virtual environment would remove the ambiguity.
• Trying to keep Python 2 and Python 3 packages aligned manually without explicit interpreter commands.

Make the Interpreter Choice Explicit in Documentation

If a team still has both major Python versions on some machines, write commands in docs as python3 -m pip instead of pip. That small habit removes a lot of support friction.

Old and New Projects Should Not Share Habits Blindly

If a legacy Python 2 project still exists, keep its package commands explicit without letting those habits leak into modern Python 3 project setup. Clarity matters more than nostalgia here.

Summary

• Use python3 -m pip for Python 3 and python2 -m pip for Python 2.
• Avoid bare pip when multiple Python versions are installed.
• Verify package ownership with pythonX -m pip --version.
• Prefer virtual environments for project work.
• The correct pip is the one owned by the interpreter that will run your code.