带有 python 3.4 的 Mac 上的虚拟环境答案

【问题标题】：Virtual Env on Mac with python 3.4带有 python 3.4 的 Mac 上的虚拟环境
【发布时间】：2015-10-06 15:34:37
【问题描述】：

我正在尝试启动并运行一个 django 项目，并且我正在运行 django，但是我在使用 python 的 virtualenv 时遇到了问题。

这是我的错误（在终端打开时显示）

/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
virtualenvwrapper.sh: There was a problem running the initialization hooks. 

If Python could not import the module virtualenvwrapper.hook_loader,
check that virtualenvwrapper has been installed for
VIRTUALENVWRAPPER_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python and that PATH is
set properly.

这是我的 .bash 个人资料的样子：

# Setting PATH for Python 3.4
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
export PATH

# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH

export WORKON_HOME=$HOME/.virtualenvs
source     /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
export PIP_VIRTUALENV_BASE=$WORKON_HOME
if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi

我对命令行的东西和虚拟环境很陌生，所以我可能不知道我做错了一些“明显”的事情。谢谢。

【问题讨论】：

尝试评论PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}和下一行
同样的错误。不过还是谢谢。
您是否尝试过使用mkvirtualenv --python /path/to/python3.4 venv_name 指定要使用的python 版本？
这是我一直在努力解决的问题之一，如何让 virtualenv 以不同版本的 python 为目标。一会儿我试试，谢谢！
无耻插件：如果 virtualenvwrapper 给你带来问题，也许你可以试试我自己的 Pew？ github.com/berdario/pew

标签： python macos bash virtualenv virtualenvwrapper

【解决方案1】：

首先是命令行shell的一些基础知识：

PATH 是一个包含文件系统目录列表的环境变量。当您键入诸如ls、python 或virtualenvwrapper.sh 之类的命令时，您的shell 将从列出的第一个目录开始搜索每个目录。要查看您当前的 PATH 类型：

$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

要查看给定命令将解析到将要运行的程序的位置，请使用which 命令：

$ which ls
/bin/ls

现在，在您的示例中，您首先将 Python 3.4 位置添加到 PATH，然后再添加 Python 2.7 位置。后一个位置将首先出现在您的 PATH 中。因此，所有与 Python 相关的命令首先会尝试运行 Python 2.7，如果在其中找不到命令，它接下来会在您的 Python 3.4 安装中搜索。

您似乎已经为 Python 3.4 安装了 virtualenvwrapper，但是当您从该行运行 virtualenvwrapper.sh 时：

source     /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh

您正在显式运行为 Python 3.4 安装的 virtualenvwrapper.sh。这会在运行 Python 2.7 的位置运行 python 命令，但似乎没有安装 virtualenvwrapper，如下错误消息所示：

/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper

如果您尝试将 Python 2.7 位置添加到您的 PATH 中并且它不起作用，您必须记住对您的 .bash_profile 所做的更改不会自动反映在您的终端中。您必须创建一个新的终端会话，并且该新会话将读取您的新 .bash_profile。

如果您试图让命令 virtualenv 解析为两个不同的 Python，那根本不可能。它始终会根据 PATH 上的位置顺序解析为一个特定的 Python。 VirtualEnv 确实安装了命令的替代版本，名称中内置了 Python 的版本。使用命令 virtualenv-3.4 和 virtualenv-2.7 为每个不同的 Python 创建虚拟环境。

所有这一切的关键是记住 PATH 用于解析正在运行的程序的绝对路径位置。使用echo $PATH 和which 命令来帮助您了解最终路径是如何被解析的。

这可能看起来很乏味，但输入完整的绝对路径总是会避开 PATH 解析的魔力：

$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv

尝试在操作路径的过程中使用较小的步骤。只使用virutalenv-3.4 来制作 Python 3.4 虚拟环境，并且只在需要时引入 virtualenvwrapper，并且在您对 shell 环境的理解更加扎实之后。

最后，即使是专业人士也可能因玩操纵路径的游戏而被绊倒。您最终会尝试获取一堆不同的应用程序位置并将它们全部扁平化到一个命名空间中。在某些时候，冲突可能变得无法解决。诸如Buildout 之类的Python 安装工具有它自己的学习曲线，但它硬编码了它安装的每个python 脚本的python 绝对路径。硬编码绝对路径是处理极端极端情况的唯一方法，例如同时拥有两个 Python 3.4 构建，其中您有两个脚本，每个脚本需要在同一 Python 的两个不同构建上运行。在生产环境中也需要硬编码绝对位置，因为这样您的应用程序就不会受到 bash shell 的任何更改的影响。如果您忘记了 PATH 的必需顺序，或者其他系统管理员修改了 PATH，您不会发现您的应用程序意外中断。

【讨论】：