Introduction

You can tell pip to install or upgrade everything listed in requirements.txt, but the outcome depends on how those requirements are written. If the file pins exact versions, pip will honor those pins rather than jumping to the newest release. A safe upgrade workflow starts with understanding whether you want to reinstall the declared versions, upgrade within allowed ranges, or deliberately move the dependency file itself to newer versions.

The Basic Command

To install or upgrade the packages declared in a requirements file:

python -m pip install --upgrade -r requirements.txt

This tells pip to read the file and upgrade packages as needed to satisfy those requirements.

Important nuance:

• if the file says requests==2.31.0, pip will install exactly 2.31.0
• if the file says requests>=2.31.0, pip may install a newer compatible release
• if the file says just requests, pip will usually install the newest available version

So the command upgrades relative to the requirement specification, not relative to "latest everything no matter what."

See What the File Actually Means

A file like this is pinned:

numpy==1.26.4
pandas==2.2.2
requests==2.32.3

Running pip install --upgrade -r requirements.txt here will not move those packages beyond the pinned versions.

A file like this is range-based:

numpy>=1.26
pandas>=2.2
requests>=2.32

Now pip has room to pick newer releases.

That distinction explains why many people think --upgrade "does nothing" when the real issue is that the file pins exact versions.

Upgrade Installed Packages and Rewrite the File

If you actually want to move the dependency file forward, one common workflow is:

1. upgrade packages in the environment
2. run tests
3. freeze the new environment back into a requirements file

Example:

python -m pip install --upgrade requests pandas numpy
python -m pip freeze > requirements.txt

This is simple, but it can also capture many transitive dependencies that you may not want to manage manually. For larger projects, tools like pip-tools are often better for curated upgrades.

Use a Virtual Environment

Always upgrade in a virtual environment unless you have a very specific system-level reason not to.

1python -m venv .venv
2source .venv/bin/activate
3python -m pip install --upgrade pip
4python -m pip install --upgrade -r requirements.txt

This keeps the upgrade isolated and makes rollback easy. It also prevents one project from silently changing another project's dependency set.

Dry-Run Thinking and Safer Review

Before a large upgrade, inspect what is outdated:

python -m pip list --outdated

This gives you a better picture of which dependencies are candidates for change. Then you can decide whether to:

• upgrade everything
• upgrade a small set first
• keep some packages pinned for compatibility reasons

Blindly upgrading a large environment and only then discovering a breaking change is usually avoidable.

Requirements Files Versus Modern Dependency Management

requirements.txt is still common, but it is a low-level format. If your project has more than a few dependencies, consider whether you need:

• a primary input file for direct dependencies
• a compiled lock file for exact versions
• a repeatable upgrade workflow

That is why many teams use pip-tools, Poetry, or another dependency manager instead of editing a single flat requirements file forever.

Common Pitfalls

• Expecting --upgrade to bypass exact version pins in requirements.txt.
• Upgrading global Python packages instead of using a virtual environment.
• Overwriting requirements.txt with pip freeze without reviewing the new dependency graph.
• Upgrading everything at once without running tests immediately after.
• Treating direct dependencies and transitive dependencies as if they should always be managed the same way.

Summary

• The core command is python -m pip install --upgrade -r requirements.txt.
• Whether packages actually move depends on the version specifiers inside the file.
• Exact pins prevent automatic upgrades beyond those pinned versions.
• Use a virtual environment and review outdated packages before large upgrades.
• If you want maintainable upgrades over time, consider a workflow that separates direct dependency intent from fully pinned lock output.