Yes, in current pip releases. The pip lock command resolves requirements and writes a pylock.toml file. Its documentation marks it experimental and says the file is only guaranteed valid for the current Python version and platform. Use it as a reviewable record, and do not assume one file works on every machine.
What the command does
The pip reference describes it as locking packages and their dependencies from several kinds of input: package indexes using requirement specifiers, VCS project URLs, local project directories, and local or remote source archives. It also accepts requirements files, in the usual format or in pylock.toml form, with the note that pylock.toml support is experimental.
python -m pip lock -r requirements.txt -o pylock.toml
The default output name is pylock.toml, and a dash sends it to standard output. Other options include constraint files, a build-constraint option for build dependencies, and reading dependencies from a script that uses inline metadata.
Why it differs from pip freeze
A freeze lists what is installed in one environment. A lock is produced by resolving, so it can be created without installing and reviewed before anything runs. If you want the file format explained, see what pylock.toml is.
| Question | pip freeze | pip lock |
|---|---|---|
| Needs an installed environment | Yes | No |
| Shows transitive dependencies | Yes, as installed | Yes, as resolved |
| Format | requirements.txt lines | pylock.toml |
| Stability | Long established | Marked experimental |
For a deeper look at what a freeze misses, see does pip freeze pin transitive dependencies.
The platform caveat
The documentation says the generated lock file is only guaranteed to be valid for the current Python version and platform. In practice that means a lock made on a Linux build host may not describe what a macOS developer or a different Python version would resolve.
Options for teams with mixed environments:
- Generate the lock in the same container image you deploy, and treat that as the source of truth for production.
- Generate one lock per supported platform and Python version.
- Keep your source requirements file alongside, and regenerate when you change targets.
What a lock does not decide
A lock records which versions were resolved. It does not decide whether those versions are safe. Review remains your job: look at new packages, new maintainers and sudden version jumps in the diff of the lock file.
It also sits upstream of install time controls. Hash-checking mode and wheel only installs are still how you constrain what lands on a machine. See how pip hash checking works.
Using it with care
- Commit the lock file and review changes like code.
- Pin the pip version in CI, since the feature is experimental and behaviour may change.
- Do not delete your source requirements. A lock is output, not intent.
- Compare the lock with what a scanner reports so you notice drift.
Safeguard's SBOM generation and dependency scanning record the resolved package set of a project, which pairs well with a committed lock file for comparison. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how new advisories are matched against a package set that has not changed.
Quick check
Is pip lock stable enough for production pipelines?
The documentation labels it experimental. Pin your pip version and be ready to adjust.
Can one pylock.toml serve Windows, macOS and Linux?
Not guaranteed. The docs say the file is valid for the current Python version and platform.
Sources
Last reviewed: 19 October 2026.
