Python Tools Are Quickly Adopting the New pylock.toml Standard

Just two weeks after PEP 751 was accepted, the new pylock.toml lock file format is already gaining traction across Python tooling. Python core developer Brett Cannon has been actively tracking adoption progress on Mastodon, highlighting how quickly key tools are aligning around the new standard.

Introduced to improve reproducibility, security, and interoperability, pylock.toml provides a standardized way to record exact dependency versions, hashes, and install metadata. Now, several major tools are moving quickly to adopt the format, signaling early momentum toward ending lock file fragmentation in Python.

pip Gains a lock Command#

The biggest milestone so far: pip will soon natively support generating pylock.toml.

Merged into pip’s main branch and slated for release in version 25.1, the new pip lock command outputs a PEP 751-compliant lock file.

The command works similarly to pip install --dry-run --ignore-installed but writes a complete lock file instead of installing packages. It avoids some advanced features (like environment markers) for now but already supports core PEP 751 functionality, including relative paths and hash validation.

Although marked as experimental, pip lock represents a major step forward. For the first time, Python’s default package installer can generate reproducible environments in a standardized format.

pip-audit Adds pylock Support#

Security tooling is also embracing the new format. Version 2.9.0 of pip-audit added support for scanning pylock.toml files, allowing for vulnerability analysis of locked environments.

The tool now automatically looks for pylock.*.toml alongside pyproject.toml, making it easier to audit dependencies with exact hashes and metadata. This tightens the feedback loop between environment definition and security analysis.

pip-tools Starts Exploring Integration#

The maintainers of pip-tools, a popular tool for compiling requirements.txt, have opened discussions on how best to support pylock.toml.

While the work is still early, the project’s direction is clear. PEP 751 support is on the roadmap, and maintainers are actively considering whether to extend existing commands like pip-sync or create a new tool purpose-built for pylock-style installs.

Packaging Library Gains Marker Support#

Behind the scenes, foundational libraries are also preparing for PEP 751.

A recent PR to the packaging library added support for extras and dependency_groups—two new marker types introduced by the lock file spec. These markers are used to define optional dependencies and groupings in a structured, portable way.

Thanks to a flexible context-based evaluation model, the new markers behave correctly based on whether they’re being used in a lock file, requirement spec, or package metadata. This work unlocks richer environment definitions and unblocks pylock support in higher-level tools like PDM.

PDM Adds Export Support (and Plans Full Migration)#

PDM, one of the early adopters of lock file workflows, now supports exporting to pylock.toml. Version 2.24.0 includes a new export mode that generates a compliant lock file from a PDM-managed project.

Even more notably, PDM maintainer Frost Ming confirmed that the project plans to fully migrate to pylock.toml in the future, eventually replacing its own pdm.lock format altogether.

With pip, pip-audit, and PDM all adopting the new standard, and pip-tools preparing to follow, pylock.toml is quickly becoming the single source of truth for Python dependency locking.

A Turning Point for Python Packaging#

In just a matter of weeks, PEP 751 has moved from a long-discussed proposal to a fast-emerging standard. The growing adoption of pylock.toml across installers, auditing tools, and lock file generators marks a significant shift toward modern, reproducible Python environments.

As more tools adopt the format and more workflows standardize around it, the benefits of a unified, secure, and extensible lock file will only grow. This marks real progress toward ending the lock file fragmentation that’s long complicated Python packaging.