如何在Rust Cargo的config.toml中前置PATH环境变量以使用Python虚拟环境

问题 #

我正在使用编译时内联Python（compile time inline-python），希望在构建和测试时使用Python虚拟环境。参考激活虚拟环境的Shell脚本，我打算在编译时把venv/bin路径前置到现有PATH中，完成后再恢复。相关脚本片段如下：

...
VIRTUAL_ENV="/Users/<some-path>/<cargo-project>/venv"
export VIRTUAL_ENV

_OLD_VIRTUAL_PATH="$PATH"
PATH="$VIRTUAL_ENV/bin:$PATH"
export PATH
...

请问这种方式是否可行？如果可行，具体该如何操作？

目前测试发现调用的是系统Python，测试代码如下：

#[cfg(test)]
mod tests {

    use std::env;

    use ct_python::ct_python;

    static python_bin: &'static str = ct_python! {
    import sys
    print('"' + "{}".format(sys.executable) + '"')
    };

    static python_path: &'static str = ct_python! {
    import sys
    print('"' + "{}".format(sys.path) + '"')
    };

    #[test]
    fn venv_test() {
        match env::var("VIRTUAL_ENV") {
            Ok(v) => println!("{}", v),
            Err(e) => println!("{}", e)
            
        }
    }

    #[test]
    fn path_print_test() {        
        println!("bin: {}", python_bin);
        println!("path: {}", python_path);
    }
}

测试输出：

running 1 test
bin: /Users/<username>/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/rustc
path: ['/opt/homebrew/Cellar/python@3.10/3.10.9/Frameworks/Python.framework/Versions/3.10/lib/python310.zip', '/opt/homebrew/Cellar/python@3.10/3.10.9/Frameworks/Python.framework/Versions/3.10/lib/python3.10', '/opt/homebrew/Cellar/python@3.10/3.10.9/Frameworks/Python.framework/Versions/3.10/lib/python3.10/lib-dynload', '/opt/homebrew/Cellar/python@3.10/3.10.9/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages', '/opt/homebrew/opt/python-tk@3.10/libexec']
test signal_proc::tests::path_print_test ... ok

我原本以为sys.path应该输出./venv/bin才能使用虚拟环境里的Python库，且只需为Cargo前置PATH即可。

解决方案 #

1. 方式可行性 #

你的思路完全可行，但需要纠正几个关键认知：

• ct_python在编译阶段执行，会优先调用PATH中排在最前面的python可执行文件，所以前置虚拟环境bin目录到PATH，确实能让它优先使用虚拟环境内的Python解释器。
• 测试中sys.executable显示为rustc是ct_python的正常机制：它将Python代码嵌入编译流程，由rustc触发执行，因此sys.executable会指向rustc，这不影响实际使用虚拟环境的Python。
• 你对sys.path的理解有误：sys.path是Python查找模块的路径列表，虚拟环境的第三方库存放在venv/lib/pythonX.X/site-packages目录下，而非venv/bin。激活虚拟环境后，Python会自动将对应site-packages路径加入sys.path。

2. 具体操作步骤 #

方法一：临时设置环境变量执行Cargo

在终端中执行以下命令（替换为你的虚拟环境实际路径）：

# 设置虚拟环境变量
export VIRTUAL_ENV="/Users/<some-path>/<cargo-project>/venv"
export PATH="$VIRTUAL_ENV/bin:$PATH"
# 执行构建或测试
cargo build
cargo test
# 可选：恢复原有PATH（新开终端会自动重置）
unset VIRTUAL_ENV
export PATH="$PATH:$VIRTUAL_ENV/bin" # 反向移除前置路径，或直接关闭终端

如果不想影响当前终端环境，可用子shell执行：

(
  export VIRTUAL_ENV="/Users/<some-path>/<cargo-project>/venv"
  export PATH="$VIRTUAL_ENV/bin:$PATH"
  cargo test
)

方法二：通过Cargo配置自动注入环境变量

在项目根目录的.cargo/config.toml中添加以下配置：

[env]
VIRTUAL_ENV = "/Users/<some-path>/<cargo-project>/venv"
PATH = { value = "$VIRTUAL_ENV/bin:$PATH", relative = false }

此后每次执行cargo build或cargo test时，Cargo会自动加载这些环境变量，无需手动输入命令。

3. 验证虚拟环境是否生效 #

修改测试代码，打印虚拟环境的site-packages路径来确认：

static venv_site_packages: &'static str = ct_python! {
import site
print('"' + site.getsitepackages()[0] + '"')
};

#[test]
fn verify_venv() {
    println!("venv site-packages: {}", venv_site_packages);
}

执行测试后，若输出路径包含你的项目venv目录，说明虚拟环境已生效。

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