Yes. If you deploy a Python application, commit a lock file. Both Poetry and uv write one, and both documents say to put it in version control so everyone installs the same exact versions. The project file states what you broadly need; the lock file records what was actually resolved.
What the two files record
Poetry's documentation says that when poetry install runs with no poetry.lock present, it resolves everything in pyproject.toml, downloads the latest versions, and writes all packages and their exact versions to poetry.lock. It tells you to commit that file so all people working on the project are locked to the same versions.
The uv documentation describes uv.lock as a universal, cross-platform lockfile that captures the packages that would be installed across Python markers such as operating system, architecture and Python version. It contrasts pyproject.toml, which holds the broad requirements, with the lockfile, which holds the exact resolved versions. It also says the file should be checked in, and that it is created and updated by commands that use the project environment, such as uv sync and uv run.
What changes with a lock file
| Question | Without a lock file | With a lock file |
|---|---|---|
| Two developers install a week apart | May get different versions | Same versions |
| CI rebuilds an old commit | Resolves again today | Reproduces the recorded set |
| A new release appears in your range | Picked up silently | Picked up when you update the lock |
| Reviewing dependency changes | Hard, nothing in the diff | Visible as a lock file diff |
Workflow that works
- Keep direct requirements readable in pyproject.toml, with ranges that say what you have tested.
- Generate the lock file and commit it in the same change as any requirement edit.
- In CI, install from the lock file rather than resolving again. Check your tool's documentation for the option that fails the build when the lock is out of date.
- Update on purpose. Run an update command in a dedicated pull request, read the diff, run tests, merge.
- Rebuild images from the lock file, so what you tested is what ships.
Libraries are different
A lock file does not travel with a package you publish. Consumers resolve from your metadata, not from your lock file. The lock file is for developing and testing the library itself. So a library still needs honest ranges in its metadata, and the lock file is a convenience for your own CI.
Hashes and tampering
Whether a lock file also verifies artifact hashes depends on the tool and version, so check its documentation rather than assuming. If you rely on pip directly, its hash-checking mode verifies each file against a pinned, hashed requirements file.
Where Safeguard fits
A lock file gives you a precise list of what you ship, and Safeguard's dependency scanning and SBOM generation can turn that list into known vulnerabilities and an inventory. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Look at how the inventory lists exact resolved packages, which is the same information a lock file holds.
Click through it at your own pace, or open it full screen.
Quick check
Should I commit poetry.lock and uv.lock?
Yes for applications. Both projects say to commit the lock file so every machine installs the same versions.
Does my published library ship its lock file to users?
No. Consumers resolve from your package metadata. Your lock file is for developing and testing the library.
Sources
Last reviewed: 19 October 2026.
