Python 3.5环境下创建内置兼容版setuptools的virtualenv虚拟环境

核心问题根因 #

现有临时方案的失效风险来自虚拟环境创建初期，virtualenv会自动拉取不兼容Python3.5的最新版引导组件，一旦该组件使用了超前语法，会直接导致环境内的pip脚本无法运行，连后续降级setuptools的命令都执行不了。优化方向是从创建环节就锁死兼容版本的引导组件，跳过无必要的在线拉取逻辑。

可落地方案 #

方案1：高版本virtualenv下锁定本地引导包源 #

• 提前下载好Python3.5兼容的对应版本wheel包，存到本地固定目录：
  • 兼容setuptools版本：50.3.2
  • 兼容pip版本：Python3.5可正常运行的20.3.4版本
  • 所有wheel文件保留官方标准命名格式，不要手动修改文件名
• 创建虚拟环境时追加关键参数，绕过自动选择最新版本的逻辑：

virtualenv -p python3.5 --no-download --extra-search-dir=你的本地包存储路径 venv
source venv/bin/activate
pip install my_project

参数逻辑说明：

• --no-download：强制禁用virtualenv从线上源拉取最新引导包的默认行为
• --extra-search-dir：指定本地包目录为唯一的引导包检索路径
  之前遇到的“指定了旧版包目录但工具还是选最新版”的问题，本质是未禁用在线拉取时，本地目录仅作为线上源的补全路径，工具会优先匹配线上的最新版本；加上--no-download后工具完全走本地路径匹配，不会自动挑选最新版本。

方案2：使用Python3.5适配的旧版virtualenv作为基础工具 #

• 在当前系统的Python3.5解释器环境下，安装最后一个支持Python3.5的virtualenv版本：pip install virtualenv==16.7.12
• 该版本的virtualenv本身内置了适配Python3.5的setuptools、pip引导组件，创建虚拟环境时不会主动从线上拉取新版引导包，从根源上避免语法不兼容问题
• 后续创建环境的流程可简化为：

python3.5 -m virtualenv venv
source venv/bin/activate
pip install my_project

该方案稳定性最高，全程不依赖虚拟环境内的非兼容组件执行命令，不存在后续引导组件语法变更导致流程卡住的风险。

内容的提问来源于stack exchange，提问作者David258