What is a lockfile?
A lockfile records the exact version of every direct and transitive dependency a project uses, along with cryptographic hashes and platform-specific constraints. pyproject.toml declares version ranges like requests>=2.28; the lockfile pins those to a specific resolved version like requests==2.32.3. Anyone who installs from the lockfile gets the same packages on every machine.
uv generates uv.lock automatically when you run uv add, uv sync, or uv lock. Commit it to version control so CI and teammates install the same versions.
The Python ecosystem lacked a standardized lockfile format until PEP 751 was accepted in March 2025. Before that, each tool developed its own format:
poetry.lockfrom PoetryPipfile.lockfrom Pipenvpdm.lockfrom PDMuv.lockfrom uv- Requirements files with hashes from pip-tools
pylock.tomlfrom pip 25.1+ via the experimentalpip lockcommand (single-platform only)
Several of these tools also support writing or reading PEP 751’s pylock.toml format alongside their native lockfile, so a project’s primary lockfile and its shareable export can now be different files.
Lockfiles and security fixes
When a vulnerability is disclosed in a dependency, the lockfile is where the fix happens. The application deployer upgrades the affected package in their lockfile, not in the version specifiers of every library that transitively depends on it.
Most tools support targeted upgrades that re-resolve a single package without touching the rest of the dependency tree:
uv lock --upgrade-package urllib3pip-compile --upgrade-package urllib3poetry update urllib3After upgrading, run a vulnerability scan (uv audit or pip-audit) to confirm the fixed version landed in the lockfile. This workflow keeps version specifiers in libraries focused on compatibility while giving application deployers direct control over which versions ship to production.