virtualenv – 无站点包和点仍然可以find全球包？
我的印象是virtualenv – no-site-packages会创build一个完全独立和孤立的Python环境，但似乎并不是这样。
例如，我在全局安装了python-django，但是希望用不同的Django版本创build一个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冻结环境，我会得到很多包。 我期望对于一个新的环境 – 无站点包，这将是空白的？
$ 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 -E都不起作用。 但是，如果我实际上激活了virtualenv，并使用virtualenv提供的easy_install来安装pip，那么直接从内部使用pip，它似乎按预期工作，只显示virtualenv中的包
我知道这是一个非常古老的问题，但对于那些到这里寻找解决scheme的人来说：
运行pip freeze之前，不要忘记激活virtualenv （ source bin/activate ）。 否则，你将得到所有全局包的列表。
您必须确保在您创build的虚拟环境中运行pip二进制文件，而不是全局文件。
env/bin/pip freeze
看一个testing：
我们使用--no-site-packages选项创buildvirtualenv：
$ 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.
我们检查新创build的pip的freeze输出：
$ 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 （至less在我的情况下）是/usr/local/bin/pip ，这意味着当我们做pip freeze它调用这个二进制代替mytest/bin/pip 。
--no-site-packages应该顾名思义，从sys.path中删除标准的site-packages目录。 生活在标准Pythonpath中的其他任何东西都将保留在那里。
如果直接调用脚本作为script.py ，然后使用Windows默认打开程序并在虚拟环境之外打开Python，则Windows上可能会出现类似的问题。 用python script.py调用它将使用Python与虚拟环境。
当你将virtualenv目录移动到另一个目录（在Linux上），或者重命名一个父目录时，这也会发生。
为什么virtualenv点不起作用的一个可能的原因是，如果任何父文件夹的名称/Documents/project name/app有空间重命名为/Documents/projectName/app解决问题。
下面是所有pip安装选项的列表 – 我没有find任何' -E '选项，可能是旧版本了。 下面我分享一个普通的英文用法和为即将到来的SO用户工作的virtualenv 。
每件事情都很好，接受激活virtualenv （ foo ）。 它所做的只是允许我们有多个（和不同的）Python环境，即各种Python版本，或者各种Django版本，或者任何其他的Python包 – 如果我们在生产中有以前的版本，并且想要用我们的testing版来testing最新的Django版本应用。
简而言之，创build和使用（激活）虚拟环境（ virtualenv ）可以运行或testing我们的应用程序，或者使用不同的Python解释器，例如Python 2.7和3.3来testing我们的应用程序或简单的Python脚本 – 可以是全新安装（使用--no-site-packages选项）或现有/上一次安装的所有软件包（使用--system-site-packages选项）。 要使用它，我们必须激活它：
$ pip install django会将其安装到全局站点包中，并且同样得到pip freeze将给出全局站点包的名称。
而在venv dir（foo）里执行$ source /bin/activate会激活venv，ie现在任何安装了pip的东西只会被安装在虚拟env中，现在只有pip freeze不会给出全局站点包的列表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上）是我的path名包含$ 。 当我在$ dir之外创build一个virtualenv时，它工作正常。
奇怪的。
Juniper有答案。
清除PYTHONPATH：
export PYTHONPATH=
然后创build并激活虚拟环境：
virtualenv foo . foo/bin/activate
只有这样：
pip freeze
