为何Makefile中需重复export VIRTUAL_ENV环境变量？

从理论逻辑上讲，你在Makefile开头通过export VIRTUAL_ENV := ${REPO_ROOT}/venv导出的变量，应该会被传递给执行recipe的shell进程，本不需要在recipe内重复执行export操作。但出现你描述的必须重复执行的情况，大概率是以下原因之一：

1. 虚拟环境未提前创建，PATH设置无效 #

你在Makefile中给PATH添加了${VIRTUAL_ENV}/bin和${VIRTUAL_ENV}/Scripts路径，但如果虚拟环境还未创建，这些目录根本不存在。shell会自动忽略PATH中不存在的路径，导致执行python时调用的是系统默认的Python解释器。

此时即便VIRTUAL_ENV环境变量存在，系统级的pip也不会自动将包安装到虚拟环境——pip的安装路径是和当前调用的Python解释器绑定的，只会安装到该解释器对应的site-packages目录下。

你在recipe中重复export的操作可能只是巧合，真正解决问题的核心应该是先创建虚拟环境，比如添加一个专门的规则：

venv:
    python -m venv ${VIRTUAL_ENV}
install: venv show-python
    python -m pip install -r requirements-dev.txt --progress-bar off

2. Make变量展开时机的问题 #

你用REPO_ROOT = $(shell pwd)定义的是递归展开变量，这个变量会在每次被引用时重新执行$(shell pwd)命令。如果Make执行过程中工作目录发生了变化（比如其他recipe中有cd操作），VIRTUAL_ENV的值会变成新的工作路径，和预期的虚拟环境路径不符。

而在recipe中手动export时，${VIRTUAL_ENV}是在Make解析阶段就展开的，使用的是初始工作路径，因此能正确指向虚拟环境。建议把REPO_ROOT改为立即展开变量，避免路径变化带来的问题：

REPO_ROOT := $(shell pwd)

3. Shell环境变量继承异常 #

某些场景下，Make无法将export的变量正确传递给执行recipe的shell进程：

• 如果使用了make -e选项，系统环境中的同名变量会覆盖Makefile中定义的变量，导致VIRTUAL_ENV的值不是你预期的路径；
• 若你的shell启动时有自定义配置会重置环境变量，可能会丢失Make传递的VIRTUAL_ENV变量。此时在recipe中显式export可以确保变量存在于当前shell进程的环境中。

4. 旧版pip的兼容性问题 #

较老版本的pip可能存在环境变量识别逻辑的缺陷，无法正确读取从父进程（Make）传递过来的VIRTUAL_ENV变量。在recipe中显式export可以确保变量被当前shell进程标记为“导出”状态，从而被pip识别到。升级pip到最新版本通常可以解决这个问题。

验证方法 #

你可以在install recipe中添加一行命令，验证VIRTUAL_ENV是否被正确传递到shell：

install: show-python
install:    ## Install all dev dependencies into a local virtual environment.
    @echo "当前shell中的VIRTUAL_ENV: $$VIRTUAL_ENV"
    python -m pip install -r requirements-dev.txt --progress-bar off

如果输出为空，说明Make的export未生效，需要排查上述几种情况；如果输出正确路径但pip仍未安装到虚拟环境，则问题出在pip与Python解释器的绑定关系上。

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