我的印象是virtualenv --no-site-packages会创建一个完全独立且孤立的Python环境，但它似乎并没有。
例如，我在全局安装了python-django，但希望使用不同的Django版本创建virtualenv。
$ virtualenv --no-site-packages foo
New python executable in foo/bin/python
Installing setuptools............done.
$ pip -E foo install Django
Requirement already satisfied: Django in /usr/share/pyshared
Installing collected packages: Django
Successfully installed Django
据我所知，上面的pip -E foo install应该重新安装新版本的Django。另外，如果我告诉pip冻结环境，我会得到很多包。我希望，对于--no-site-packages的新环境，这将是空白的吗？
$ pip -E foo freeze
4Suite-XML==1.0.2
BeautifulSoup==3.1.0.1
Brlapi==0.5.3
BzrTools==1.17.0
Django==1.1
... and so on ...
我误解了--no-site-packages应该如何运作？
我有这样的问题，直到我意识到（早在我发现virtualenv之前），我已经在我的.bashrc文件中添加了目录到PYTHONPATH。由于事先已经超过一年，我没有立刻想到这一点。
这是所有pip安装options的列表 - 我没有找到任何'-E'选项，可能是旧版本有它。下面我将为即将到来的SO用户分享一个简单的英语用法和virtualenv的工作。
每件事似乎都很好，接受激活virtualenv（foo）。所有这一切都是允许我们拥有多个（和变化的）python环境，即各种Python版本，或各种Django版本，或任何其他Python包 - 如果我们有一个以前的版本正在生产，并希望测试最新的Django版本与我们应用。
简而言之，创建和使用（激活）虚拟环境（virtualenv）可以运行或测试我们的应用程序或使用不同的Python解释器（即Python 2.7和3.3）的简单python脚本 - 可以是全新安装（使用--no-site-packages选项）或所有包从现有/最后设置（使用--system-site-packages选项）。要使用它，我们必须激活它：
$ pip install django将把它安装到全局站点包中，同样获取pip freeze将给出全局站点包的名称。
而在venv dir（foo）中执行$ source /bin/activate会激活venv，即现在安装pip的任何东西都只会安装在虚拟环境中，而且现在pip冻结不会给出全局网站包python包的列表。一旦激活：
$ virtualenv --no-site-packages foo
New python executable in foo/bin/python
Installing setuptools............done.
$ cd foo
$ source bin/activate
(foo)$ pip install django
在(foo)标志之前的$表示我们正在使用虚拟python环境，即任何带有pip的东西 - 安装，冻结，卸载都将仅限于此venv，并且对全局/默认Python安装/包没有影响。
我遇到了同样的问题。对我来说（在Ubuntu上）的问题是我的路径名包含$。当我在$ dir之外创建virtualenv时，它运行正常。
奇怪的。
最终我发现，无论出于什么原因，pip -E都无法正常工作。但是，如果我实际上激活virtualenv，并使用virtualenv提供的easy_install来安装pip，那么直接从内部使用pip，它似乎按预期工作，只显示virtualenv中的包
您必须确保在所创建的虚拟环境中运行pip二进制文件，而不是全局二进制文件。
env/bin/pip freeze
看测试：
我们使用--no-site-packages选项创建virtualenv：
$ virtualenv --no-site-packages -p /usr/local/bin/python mytest
Running virtualenv with interpreter /usr/local/bin/python
New python executable in mytest/bin/python
Installing setuptools, pip, wheel...done.
我们从新创建的freeze检查pip的输出：
$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0
但如果我们使用全球pip，这就是我们得到的：
$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2
也就是说，pip已在整个系统中安装的所有软件包。通过检查which pip，我们得到（至少在我的情况下）类似/usr/local/bin/pip，这意味着当我们做pip freeze时，它调用这个二进制而不是mytest/bin/pip。
我知道这是一个非常古老的问题，但对于那些到这里寻找解决方案的人来说：
在运行source bin/activate之前，不要忘记激活virtualenv（pip freeze）。否则，您将获得所有全局包的列表。
顾名思义，--no-site-packages应该从sys.path中删除标准的site-packages目录。生活在标准Python路径中的任何其他东西都将保留在那里。
暂时清除PYTHONPATH：
export PYTHONPATH=
然后创建并激活虚拟环境：
virtualenv foo
. foo/bin/activate
只有这样：
pip freeze
如果您直接将脚本调用为script.py，然后使用Windows默认开启工具并在虚拟环境外打开Python，则Windows上可能会出现类似的问题。使用python script.py调用它将在虚拟环境中使用Python。
当您将virtualenv目录移动到另一个目录（在Linux上）或重命名父目录时，似乎也会发生这种情况。
virtualenv pip不起作用的一个可能原因是，如果任何父文件夹的名称中有空格，/Documents/project name/app将其重命名为/Documents/projectName/app可以解决问题。