How to pin and hash Python dependencies

A requirements.txt that says flask>=2.0 is a promise to install whatever is newest on the day someone runs pip install. That is fine for a notebook and a risk for anything you deploy. Three changes make an install repeatable and much harder to tamper with.

The categories this tool uses

index-override — a second package index (--extra-index-url) that lets a same-named public package outrank yours.
insecure-source — a plain-http index or URL, or --trusted-host, which removes TLS protection.
vcs-unpinned — a git dependency following a branch or tag instead of a full commit hash.
url-dependency — a direct URL with no #sha256= hash.
no-version — a bare package name with no constraint at all.
range-version — a >=, ~=, < or wildcard range that lets the resolved version drift.
no-hashes — an exact pin with no --hash (only reported with the require-hashes option).
editable — an -e install that cannot be reproduced from a registry.
duplicate — the same package listed twice, which pip resolves by applying both constraints.

Checklist

Keep loose intent in requirements.in (flask>=2.0) and generate the locked file: pip-compile --generate-hashes requirements.in or uv pip compile --generate-hashes requirements.in -o requirements.txt.
Install with pip install --require-hashes -r requirements.txt so any file that does not match its hash fails the build.
Use one index. If you need a private index, put it behind a proxy that serves both, rather than adding --extra-index-url.
Pin git dependencies to a full 40-character commit, not a branch or tag.
Add node requirements-check.mjs --fail-on medium to CI so a loose line cannot be committed silently.

What this does not tell you

It scans the text of the file. It does not run pip's resolver, read transitive dependencies, or check pinned versions against a vulnerability database, so a fully pinned file can still contain a vulnerable release. It is a heuristic and is not security advice.