pip 26.1 发布：lockfile 和依赖冷却，补的是 Python 依赖管理的地基

pip 26.1 里最有意思的，不是“pip 又更新了”，而是两个过去常被默认工具绕开的老问题被摆上了台面：依赖能不能稳定复现，刚发布的新包能不能别立刻进生产链路。

这次更新有三个事实锚点：pip 26.1 不再支持 Python 3.9；新增实验性的 pip lock，可以生成 pylock.toml；新增 --uploaded-prior-to PXD，可以限制只安装上传时间早于 X 天的包版本。我的判断很简单：这不是一次普通小版本迭代，更像 pip 在补 Python 依赖管理的地基。

pip 26.1 先影响谁：开发者和工程团队该动哪里

pip 26.1 停止支持 Python 3.9。Python 3.9 已进入 EOL，这个调整符合生命周期节奏。但现实里会有一点别扭：macOS 默认的 python3 仍可能是 Python 3.9。

所以测试 pip 26.1 时，不能只敲系统自带的 python3。原始示例里使用的是 Python 3.14：先安装 Python 3.14，再创建虚拟环境，升级 pip，确认版本为 pip 26.1。

这对两类人最直接。

这一步不性感，但很关键。依赖管理的问题，很多时候不是工具命令写错，而是本机、CI、线上三套环境各跑各的。

pip lock 解决的是“今天到底装了什么”

pip lock datasette llm 会解析 Datasette、LLM 以及它们的依赖，并生成一个 pylock.toml 文件。示例结果是 519 行。

这 519 行的意义不在于文件多完整，而在于把一次依赖解析结果记录下来。以前很多项目依赖 requirements.txt，它简单、通用，但更像安装清单。它不天然等同于跨平台、包含完整解析结果的锁文件。

Poetry、uv、PDM 这些工具早就把 lockfile 当成核心能力。JavaScript 生态里的 package-lock.json、pnpm-lock.yaml 也是同一类思路：别每次安装都现场猜一遍依赖树。

pip lock 的价值就在这里。它让默认工具开始靠近可复现安装的方向。

但边界也要讲清。现在不能把 pip lock 直接看成已经成熟到等同于其他生态 lockfile 方案。更稳妥的说法是：pip 26.1 开了一个口子，先让默认工具具备生成锁文件的能力。

对团队来说，短期最现实的用法不是立刻替换所有既有工具，而是做三件事：

• 在新项目或低风险项目里试用 pip lock，观察 pylock.toml 是否适合现有流程。
• 在 CI 中区分“解析依赖”和“安装依赖”，减少每次构建现场重新解析。
• 对已有 Poetry、uv、PDM 项目保持克制，不要为了追新把稳定流程拆掉。

主线还是那句话：pip 不是一夜之间变成完整依赖管理平台，但它开始补默认工具最该补的那块。

--uploaded-prior-to 是安全缓冲，不是安全保险

pip 26.1 另一个值得看的是 dependency cooldown。新参数 --uploaded-prior-to PXD 用来限制只安装上传时间早于 X 天的包版本。

这里的 PXD 遵循 ISO 8601 duration 风格，但当前只支持按天。比如 P4D，意思是至少上传满 4 天。

原始示例里，LLM 0.31 是三天前发布的。执行 pip install llm --uploaded-prior-to P4D 后，安装到的是 LLM 0.30，而不是 0.31。

这个例子很直观：如果一个包刚发布 3 天，而策略要求只装 4 天前上传的版本，那么它会被跳过。

这对供应链安全有现实意义。PyPI、npm 这类生态都面对过依赖混淆、账号接管、恶意更新等风险。攻击者最喜欢的窗口，往往就是新版本刚上传后，被 CI、部署脚本、开发机快速拉取的那段时间。

冷却期不能识别恶意代码。它也不能替代代码审计、私有镜像、签名、SBOM 或内部准入流程。

它能做的事更窄，也更实际：把“刚上传就被自动安装”的概率往后推几天。对自动化构建越多、依赖更新越频繁的团队，这个缓冲越有价值。

接下来最该看两个变量。

如果这两个能力只停留在个人试用层面，影响会比较有限。若它们进入团队模板，Python 项目的默认安装习惯才会真的变。