Introduction

When you remove a package with pip uninstall, pip only removes the package you name. It does not automatically uninstall the dependencies that were installed alongside it, because pip cannot safely assume those packages are no longer needed by something else in the same environment.

What pip uninstall Actually Removes

Suppose you install a package that depends on several others:

1python -m venv .venv
2source .venv/bin/activate
3python -m pip install requests
4python -m pip show requests

If you later run:

python -m pip uninstall -y requests

requests is removed, but packages such as urllib3, idna, charset-normalizer, and certifi usually remain installed. That behavior is intentional.

The reason is simple: a dependency may have been installed for more than one top-level package. If pip aggressively removed it, uninstalling one package could break another package that still depends on it.

You can verify what is still installed:

python -m pip list

This often surprises developers who expect package managers to perform automatic dependency cleanup. Some ecosystem tools do that, but plain pip does not.

Why pip Behaves Conservatively

pip focuses on installing and uninstalling distributions, not on maintaining a full dependency ownership graph the way some other package managers do. In a shared environment, it is difficult to know whether a dependency is now unused or whether another project or direct install still relies on it.

For example, imagine this sequence:

python -m pip install requests
python -m pip install boto3

Now remove requests. A leftover package might still be required by boto3 or another dependency chain. Keeping the dependency is safer than guessing wrong.

That conservative model is one reason Python development works best with isolated virtual environments. Instead of trying to prune a long-lived global environment perfectly, create a fresh environment per project and delete the whole environment when the project is no longer needed.

Safer Ways to Clean Up Dependencies

The simplest cleanup strategy is to recreate the environment from a requirements file rather than trying to hand-prune it forever.

python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

If the environment becomes messy, remove it and build it again:

1deactivate
2rm -rf .venv
3python -m venv .venv
4source .venv/bin/activate
5python -m pip install -r requirements.txt

That is usually more reliable than guessing which transitive packages are safe to remove.

If you want to inspect dependency relationships, pipdeptree is useful:

python -m pip install pipdeptree
pipdeptree

It shows which packages depend on which others, so you can see whether a leftover package is still referenced.

There are also third-party tools such as pip-autoremove that try to remove unneeded dependencies:

python -m pip install pip-autoremove
pip-autoremove requests -y

Use these tools carefully. They are convenient, but they still rely on the current environment state and can remove something you expected to keep if your environment is already inconsistent.

Prefer Virtual Environments Over Global Cleanup

If you install packages globally and reuse that interpreter for many unrelated tasks, dependency cleanup becomes messy fast. A virtual environment gives you a disposable sandbox.

For day-to-day work, the best workflow is:

• create one environment per project
• record direct dependencies in requirements.txt or pyproject.toml
• rebuild the environment when it drifts too far from the declared state

That approach avoids most uninstall confusion because you do not need the environment to live forever.

Common Pitfalls

The most common mistake is assuming pip uninstall some-package restores the environment to the exact state from before installation. It does not. Dependencies usually remain.

Another issue is deleting packages from a shared interpreter and then breaking a different project. This happens often when developers work outside a virtual environment.

Some teams also rely on pip list alone and treat every installed package as a direct dependency. In reality, many entries are transitive, so removing them manually without checking the dependency tree can destabilize the environment.

Finally, be cautious with third-party autoremove tools. They can be helpful, but they are not a substitute for environment isolation and reproducible dependency files.

Summary

• 'pip uninstall removes the named package, not its dependencies.'
• Leftover dependencies stay installed because pip cannot assume they are unused.
• Use pipdeptree if you need to inspect dependency relationships.
• Third-party cleanup tools exist, but they should be used carefully.
• The most reliable cleanup strategy is one virtual environment per project.