virtualenv --no-site-packages和pip仍在寻找全球包？

Question

我的印象是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应该如何运作？

Answer 1

我有这样的问题,直到我意识到(早在我发现virtualenv之前),我已经在我的.bashrc文件中添加了目录到PYTHONPATH.由于事先已经超过一年,我没有立刻想到这一点.

Answer 2

您必须确保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.

Answer 3

最终我发现,无论出于什么原因,pip -E都无法正常工作.但是,如果我实际上激活virtualenv,并使用virtualenv提供的easy_install来安装pip,那么直接从内部使用pip,它似乎按预期工作,只显示virtualenv中的包

Answer 4

我知道这是一个非常古老的问题,但对于那些到这里寻找解决方案的人来说:

不要忘记在运行之前激活virtualenv(source bin/activate)pip freeze.否则,您将获得所有全局包的列表.

Answer 5

--no-site-packages应该,顾名思义,删除标准的site-packages目录sys.path.生活在标准Python路径中的任何其他东西都将保留在那里.

Answer 6

暂时清除PYTHONPATH:

export PYTHONPATH=

然后创建并激活虚拟环境:

virtualenv foo
. foo/bin/activate

只有这样:

pip freeze

Answer 7

如果您直接调用脚本script.py，然后使用 Windows 默认打开程序并在虚拟环境之外打开 Python，则在 Windows上可能会发生类似的问题。调用它python script.py会在虚拟环境中使用 Python。