Run pip install with the dry-run flag and the report option. Pip resolves the requirements, lists exactly which packages and versions it would install, and writes a JSON report, without touching your environment. Diff that report against the current one to see what a security upgrade really changes.
Why preview at all
A fix pull request that says "bump one package" often changes more than one line of reality. The resolver may pull a new version of a shared library, drop a package, or add one. Reading the resolved set before you install is cheaper than debugging it after.
The pip documentation describes the two pieces. The dry-run flag tells pip not to install anything and only print what would be done. The install report option generates a JSON report of what pip has installed, and the docs state that combined with dry-run and the ignore-installed flag it can resolve a set of requirements without actually installing them. The report can go to a file or to standard output when combined with the quiet flag.
Steps
- Resolve the current requirements into a report and save it as before.json.
- Edit the requirement or constraint to the fixed version.
- Resolve again into after.json.
- Compare the two files.
- Review every package whose version, presence or source changed.
python -m pip install --dry-run --ignore-installed --quiet \
--report before.json -r requirements.txt
Run the same command after the edit with a different report name. A plain text diff of the two JSON files is enough for a first pass, or extract the name and version pairs with a short script.
What to look for in the diff
| Change in the report | What it means | Action |
|---|---|---|
| Target package moved to the fixed version | The fix applies | Expected |
| A package you did not touch changed version | Resolver side effect | Read its changelog |
| A new package appeared | New dependency path | Review it like a new dependency |
| A package disappeared | A parent dropped it | Check nothing imports it directly |
| Version unchanged | A parent or pin blocks the fix | Find the cap before merging |
The last row matters most for security work. A pull request that claims to fix a vulnerability but leaves the version unchanged in the resolved set has fixed nothing.
Pair it with a real check
A dry run proves what pip would choose. It does not prove your code still works. After you install for real, run pip check, which verifies that installed packages have compatible dependencies and exits with a non-zero code when a requirement is missing or has the wrong version. Then run your tests.
Keep the before and after reports with the pull request. They are a small, honest record of the change, useful for reviewers and for anyone asking later what moved.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the dependency list is organised, then imagine diffing two of those lists.
Where Safeguard fits
Safeguard scans dependencies, runs reachability analysis to show which findings your code can actually reach, and can open fix pull requests through autonomous remediation. That last feature is off by default and every category starts on Manual, so a person approves each change. You can try a free scan on a repository first.
Quick check
Does dry-run install anything?
No. Pip prints what it would do and, with the report option, writes the resolved set to JSON.
What does pip check add?
It verifies that installed packages have compatible dependencies and returns a non-zero exit code when they do not.
Sources
Last reviewed: 19 October 2026.
