Python has officially standardized a lock file format with the acceptance of PEP 751 marking a significant milestone for the Python packaging ecosystem.
The new format, named pylock.toml, addresses long-standing issues with dependency management by providing a standardized way to record exact package versions, file hashes, and installation sources to ensure reproducibility and enhance security.
“Currently, no standard exists to create an immutable record, such as a lock file, which specifies what direct and indirect dependencies should be installed into a virtual environment,” states the PEP documentation.
This gap has led to fragmentation, with at least five well-known solutions in the community: PDM, pip freeze, pip-tools, Poetry, and uv.
The new TOML-based format is designed to be human-readable while being machine-generated, offering several security advantages over existing approaches like requirements files:
Security-First Approach
Unlike requirements.txt files, which make file hash validation entirely optional, pylock.toml requires hashes for all packages, providing stronger security guarantees against supply chain attacks.
The format also records file sizes, upload times, and package sources to facilitate auditing.
“The file format should promote good security defaults. As the format is not meant to be human-writable, this means having tools provide security-related details is reasonable and not a costly burden,” the PEP explains.
The new standard introduces the concept of “lockers” (tools that write lock files) and “installers” (tools that install from lock files), allowing for a clear separation of concerns.
This means cloud hosting providers can implement their own installers without needing a Python interpreter.
The format supports both single-use and multi-use lock files. Single-use files are similar to requirements.txt files and serve a specific purpose, while multi-use files represent multiple use cases within a single file through extras and dependency groups.
Each package entry can include:
- Normalized package name
- Exact version
- Environment markers for conditional installation
- Python version compatibility requirements
- Hash values for file verification
- File sizes for validation
- Upload timestamps for auditing
- Source locations (URLs or paths)
Brett Cannon, the author of PEP 751, notes that the standard “replaces PEP 665” and aims to unify the ecosystem around a single format that all tools can support.
The standardization comes as Python joins other language ecosystems like JavaScript (package-lock.json), Rust (Cargo.lock), and PHP (composer.lock) that already have established lock file formats.
This development for enterprises and security teams means better auditing capabilities, more reliable builds, and improved protection against dependency confusion attacks.
By eliminating dependency resolution at install time, installations become faster and more predictable, critical for CI/CD pipelines and production deployments.
As stated in the PEP, “Having the installer do a resolution also simplifies their implementation, centralizing complexity in lockers,” which should lead to more robust tooling across the Python ecosystem.
Primary Python packaging tools are expected to adopt the new standard as their primary lock file format or export target, enhancing interoperability and reducing vendor lock-in throughout the Python ecosystem.
Investigate Real-World Malicious Links & Phishing Attacks With Threat Intelligence Lookup - Try 50 Request for Free
