Pip 26.1 landed last week with two features that address longstanding pain points in the Python packaging ecosystem: dependency cooldowns, which enforce a waiting period before freshly published packages can be installed, and experimental support for pylock.toml lockfiles from PEP 751. Two CVEs were patched, and Python 3.9 was dropped.
Richard Si, pip committer, writes:
In today's world, where supply-chain attacks on the upstream projects you depend on are occurring at an increasing rate, developers need a way to give themselves time to detect and respond to these security incidents.
The cooldown mechanic is simple. Say an attacker compromises an upstream package. Under normal circumstances, every CI pipeline and developer workstation running pip install picks up the malicious version within hours. With --uploaded-prior-to=P7D, pip will only pull versions that have sat on PyPI for at least seven days. That buys the community time to catch the compromise before it reaches your builds.
The feature draws directly on William Woodruff's influential post "We should all be using dependency cooldowns". Woodruff analyzed ten prominent supply chain attacks and found compelling results:
8/10 attacks had windows of opportunity of less than a week. Setting a cooldown of 7 days would have prevented the vast majority of these attacks from reaching end users. Increasing the cooldown to 14 days would have prevented all but 1 of these attacks.
Recent incidents illustrate both the need and the limits of cooldowns. The Essential Plugin supply chain attack planted a backdoor that sat dormant for eight months before activating across 400,000 WordPress installations. The XZ Utils backdoor required two years of trust-building before the attacker made their move. A seven-day cooldown would not have caught those specific attacks, but it would catch the more common pattern of a compromised package being pulled into CI within hours of publication.
Si flags an important tradeoff: cooldowns also hold back legitimate security fixes. Teams using this feature should pair it with Dependabot or pip-audit to make sure critical patches don't get stuck behind the cooldown window.
The other big addition is experimental pylock.toml support. PEP 751 standardized this lockfile format a year ago, but until now, only uv could install from one. The -r flag now accepts pylock.toml files, meaning pip install -r pylock.toml works out of the box. With pip joining, pylock.toml has a realistic path to widespread adoption, since pip ships as the default package manager with every Python installation.
Simon Willison, creator of Datasette, tested the feature immediately and demonstrated generating a 519-line pylock.toml locking Datasette and LLM with all dependencies, then installing from it successfully. Willison also highlighted the dependency cooldowns feature, showing how --uploaded-prior-to P4D correctly returned an older version of his LLM package instead of the release he had published three days prior.
The pip team characterizes the lockfile support as experimental and reserves the right to modify or remove it without notice. A pip sync command is planned as the eventual primary interface for lockfile operations. Stéphane Bidoul championed the implementation and upstreamed pylock.toml support in the packaging library so the broader ecosystem can benefit.
On Reddit, the Python community welcomed the lockfile addition but debated whether pip's implementation matters given uv's rapid adoption. One commenter raised a governance concern about uv's corporate ownership:
Good to hear the steady improvements over pip. Despite uv being awesome, I think it's good to not get very comfortable with them now that OpenAI bought Astral.
Another argued that pip's ubiquity makes its lockfile support essential for enterprise environments where uv adoption is not straightforward:
uv feels to me like giving up too much direct control. How do I know whether or not it will be available in a client deployment? And if it isn't, do I want to ask them to go through a uv install? In both cases, I do not. pip is there for me on all the python...-slim docker images, and easy to upgrade.
Two security patches round out the release. CVE-2026-3219 fixes a bug in which pip mistook .tar.gz archives for zip files, allowing attackers to obfuscate malicious code. CVE-2026-6357 closes an arbitrary code execution hole triggered by deferred imports during pip's self-check. The vendored urllib3 also jumped from 1.x to 2.6.3, squashing three more CVEs along the way.
Pip 26.1 is available now via pip install --upgrade pip.