在全局站点软件包而不是virtualenv中进行pip安装

Question

使用pip3在a中安装软件包将virtualenv导致该软件包安装在global site-
packages文件夹中，而不是在virtualenv文件夹中。这是我在OS X
Mavericks（10.9.1）上设置Python3和virtualenv的方法：

我使用Homebrew安装了Python3：

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl

更改了中的$PATH变量.bash_profile；添加了以下行：

export PATH=/usr/local/bin:$PATH

运行which python3返回/usr/local/bin/python3（重新启动外壳程序之后）。

注意： 尽管which python3仍然返回/ usr/bin/python。

virtualenv使用安装pip3：

pip3 install virtualenv

接下来，创建一个新的virtualenv并激活它：

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

注意：如果我不指定-p python3，则virtualenv中bin文件夹中将缺少pip。

正在运行，which pip并且which pip3都返回virtualenv文件夹：

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

现在，当我尝试使用pip在已激活的virtualenv中安装Markdown时，pip将安装在全局site-
packages文件夹中，而不是virtualenv的site-packages文件夹中。

pip install markdown

运行pip list收益：

Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)

内容/Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages：

__pycache__/
_markerlib/
easy_install.py
pip/
pip-1.5.dist-info/
pkg_resources.py
setuptools/
setuptools-2.0.2.dist-info/

内容/usr/local/lib/python3.3/site-packages：

Markdown-2.3.1-py3.3.egg-info/
__pycache__/
easy-install.pth
markdown/
pip-1.4.1-py3.3.egg/
setuptools-2.0.1-py3.3.egg
setuptools.pth
virtualenv-1.11-py3.3.egg-info/
virtualenv.py
virtualenv_support/

如您所见， 全局 site-packages文件夹包含Markdown，而virtualenv文件夹则不包含。

注意：之前我在不同的VM上安装了Python2和Python3（遵循这些说明），并且Python3遇到了相同的问题。但是，在基于Python2的virtualenv中安装软件包的工作无懈可击。

任何提示，暗示……将不胜感激。

Answer 1

有趣的是您提出了这个问题，我只是遇到了完全相同的问题。我最终解决了它，但是我仍然不确定是什么原因造成的。

尝试检查您的bin/pip和bin/activate脚本。在中bin/pip，查看shebang。这是对的吗？如果不是，请更正它。然后在〜42中的〜行中bin/activate，检查您的virtualenv路径是否正确。它看起来像这样

VIRTUAL_ENV="/Users/me/path/to/virtual/environment"

如果是错误的，请更正deactivate，然后进行纠正，. bin/activate如果我们的共同问题有相同的原因，也应该可以解决。如果仍然没有，无论如何，您都处在正确的轨道上。我经历了与您一样的解决问题的例行程序，which pip一遍又一遍，遵循堆栈跟踪等。

绝对要确保

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

是您想要的，而不是引用另一个类似名称的测试项目（我遇到了这个问题，不知道它是如何开始的。我怀疑是同时运行多个virtualenvs）。

如果这些都不起作用，那么可能会采取临时解决方案，如乔·霍洛威（Joe Holloway）所说，

只需使用其完整路径运行virtualenv的pip（即，不依赖于搜索可执行路径），甚至不需要激活环境。它将做正确的事。

也许不是很理想，但是应该在紧要关头工作。

链接到我的原始问题：

VirtualEnv /
Pip尝试在全局安装软件包