pip 构建 wheel 时 hg 找不到标准库，普通 shell 却能运行

pip wheel 执行到自定义构建步骤时，hg 报 No module named '__future__'，前面还出现 .pth 处理错误和 No module named 'traceback'。同一个工具在普通 shell 正常，先查构建环境传给 Python 子进程的启动配置，别把标准库缺失当作应该再安装一个包。

pip 26.2.1、Python 3.14.7 的一条故障路径涉及旧隔离机制的 sitecustomize：处理启动钩子时清空搜索路径，遇到错误后未恢复，随后 Python 编写的系统工具也无法导入标准库。本文针对这组迹象，不涵盖所有 hg 或 wheel 构建失败。

先看最早的启动错误

保存完整构建日志，从最早的 .pth、sitecustomize 报错往下读，不能只截最后的 CalledProcessError。它通常只是说明外部命令失败，未给出失败原因。

对照实际 pip、构建解释器和 hg 的执行入口。工具脚本可能通过 shebang 使用系统 Python，构建步骤也可能直接调用另一解释器的绝对路径；hg 已经启动并报标准库导入错误，与根本找不到可执行文件不同。

在构建调用点核对传入子进程的 PYTHONPATH、PYTHONNOUSERSITE 和路径选择，不要打印整个环境。包索引认证、代理凭据等内容必须隐藏。普通 shell 的环境正常，也不能证明隔离构建中的子进程收到同样的环境。

如果只是隔离构建中缺少未声明的 pip 或其他构建依赖，应沿 构建依赖声明检查 处理；不要把它与这里连标准库都无法导入的情况混写。

系统工具不需要该 PYTHONPATH 时，局部调整子进程环境

先确认目标工具能依靠自己的解释器和已安装依赖工作，不依赖被移除的自定义模块路径。在自己维护的构建代码里，可以为这一调用复制环境并移除隔离机制传播来的 PYTHONPATH：

import os
import subprocess

child_env = os.environ.copy()
child_env.pop("PYTHONPATH", None)
revision = subprocess.check_output(
    ["hg", "id", "-i"],
    env=child_env,
    text=True,
).strip()

这是已有 Mercurial 工作副本中的读取片段；工具及其解释器必须确实可用。它只调整这次调用，不清空全局 PATH，也不修改整个构建进程的环境。若工具需要其他 Python 路径或用户 site 包，须另行核对，不能把删除环境变量当作所有 Python 子进程的固定做法。

同一构建中还有其他 Python 子进程时，逐个确认其依赖和环境需求。只修 hg 不一定让后续调用恢复；反过来，统一移除所有调用的路径也可能破坏原本正常的构建工具。

改隔离方式要保留实验选项的限制

pip 26.2 引入实验性的 --use-feature=venv-isolation，以标准虚拟环境隔离构建子进程。可在独立构建环境、保持原构建参数的前提下评估这一选项；不能将其写成所有 pip 版本都支持或已经默认启用。

它会把临时构建环境的脚本目录加入 PATH 前部，让声明的构建工具可执行。这是预期行为，不表示 PATH 被全部清空。构建若依赖启动 pip 的原虚拟环境，应先整理其依赖约定，不能期待隔离环境自动继承所有未声明包。

该实验选项与 inprocess-build-deps 的组合仍有兼容边界，私有依赖认证和构建工具路径也要验证。不要在未检查的情况下顺便打开多个实验开关。

--no-build-isolation 是另一个选择，但要求自己预装并管理全部构建依赖。若必须使用它，应使用可重建的专用环境，记录完整依赖组合；关闭隔离不等于缺失依赖由 pip 自动补齐。没有确认后续正式修复版本时，也不能承诺升级 pip 就已解决这条路径。

保存构建配置及依赖记录后，选择其中一种符合条件的方案验证。检查工具在构建内的标准库导入、版本信息生成、wheel 完整构建和安装结果，而不只看退出码。回退时恢复局部环境处理或实验参数，重新核对构建产物，避免继续使用来自失败或不同依赖组合的文件。