Introduction

When pip install package==1.2.3 appears to use the wrong version, the cache may be involved, but it is rarely the only explanation. The more common causes are a stale artifact on a private index, the resolver choosing a different final dependency set, or the install happening in a different interpreter than the one you inspect afterward. A good fix starts by proving which of those cases you are actually in.

Verify the Active Interpreter First

The fastest way to get confused is to install with one Python and inspect another. Always run pip through the interpreter you intend to use.

python -m pip install mypackage==1.2.3
python -m pip show mypackage
python -m pip list | grep mypackage

If pip show already reports the requested version, the cache is probably not the issue. If it shows something else, you now have evidence instead of a guess.

Understand What pip Actually Caches

pip caches downloaded wheels, source distributions, and some build artifacts. That is normally safe and beneficial. Problems show up when a package index republishes a different file under the same version number, or when a user assumes the top-level requirement controls every transitive dependency.

That means “pip used the wrong cached version” can really mean one of several different things:

• the cached artifact is stale
• the version on the index changed without a version bump
• another dependency forced a different final install set
• you inspected the wrong environment

Bypass the Cache Once to Test the Theory

If you suspect a stale local cache entry, do one installation without cache.

python -m pip install --no-cache-dir mypackage==1.2.3

If this suddenly produces the expected result, the cache was likely involved. At that point you can inspect the cache location and entries.

python -m pip cache dir
python -m pip cache list mypackage

Those commands are better than immediately deleting everything blindly.

Remove the Stale Cache Entry Explicitly

Once you know the cache is involved, remove the relevant entry.

python -m pip cache remove mypackage

If necessary, clear the full cache:

python -m pip cache purge

cache purge is a broad hammer. It is fine in CI or disposable environments, but on a developer machine it just means the next few installs will redownload everything.

The Resolver May Be the Real Cause

A very common misunderstanding is that pip ignored your requested version when it actually resolved the environment according to dependency constraints.

1python -m venv .venv
2source .venv/bin/activate
3python -m pip install 'urllib3==1.26.18'
4python -m pip install 'botocore==1.34.0'
5python -m pip check

If another package upgrades or downgrades urllib3, that is a resolver decision, not a cache bug. Read the installation output carefully before blaming cached files.

Private Indexes Must Treat Versions as Immutable

A large share of real cache confusion comes from internal package repositories. If a team republishes a wheel under the same version number, clients may keep using the earlier cached file. From the client side that looks like cache misbehavior, but the real problem is broken versioning discipline.

The correct fix is to publish a new version, not to replace 1.2.3 with a different artifact that is also called 1.2.3.

Use Clean Virtual Environments for Debugging

When you are unsure what pip selected, create a fresh environment and repeat the install there.

1python -m venv .venv
2source .venv/bin/activate
3python -m pip install --upgrade pip
4python -m pip install mypackage==1.2.3

This removes interference from unrelated packages and makes resolver behavior much easier to interpret.

Common Pitfalls

• Running pip from one interpreter and inspecting packages in another.
• Blaming the cache when the resolver changed the environment for legitimate dependency reasons.
• Republishing internal package artifacts under the same version number.
• Purging the entire cache before checking whether a single package entry is actually stale.
• Debugging package selection in a polluted global environment instead of a clean virtual environment.

Summary

• A wrong package version is not always a cache problem.
• Start by verifying the interpreter, the installed version, and the resolver output.
• Use --no-cache-dir to test whether the cache is involved before deleting anything.
• Remove stale cache entries explicitly when needed.
• The long-term fix is clean versioning and isolated environments, not repeated cache purges.