自定义代码在 Virtual alenv 中的位置是什么？

使用 virtualenv时应该遵循哪种目录结构？例如，如果我正在构建一个 WSGI 应用程序并创建了一个名为 foobar的 Virtual alenv，我会从一个目录结构开始，比如:

/foobar
/bin
{activate, activate.py, easy_install, python}
/include
{python2.6/...}
/lib
{python2.6/...}

一旦这种环境被创造出来，人们会把他们自己的东西放在哪里:

  • 巨蟒文件？
  • static files (images/etc)?
  • “定制”包装，比如那些在网上可以买到但在奶酪店里找不到的包装？

与 virtualenv目录的关系？

(假设我已经知道 Virtual alenv 目录本身应该放在哪里。)

50720 次浏览
小开

如果你经常只有几个项目，没有什么能阻止你为每个项目创建一个新的 viralenv，并把你的软件包放在里面:

/foobar
/bin
{activate, activate.py, easy_install, python}
/include
{python2.6/...}
/lib
{python2.6/...}
/mypackage1
__init__.py
/mypackage2
__init__.py

The advantage of this approach is that you can always be sure to find find the activate script that belongs to the project inside.

$ cd /foobar
$ source bin/activate
$ python
>>> import mypackage1
>>>

If you decide to be a bit more organized, you should consider putting all your virtualenvs into one folder, and name each of them after the project you are working on.

  /virtualenvs
/foobar
/bin
{activate, activate.py, easy_install, python}
/include
{python2.6/...}
/lib
{python2.6/...}
/foobar
/mypackage1
__init__.py
/mypackage2
__init__.py

这样，当出现问题时，您总是可以使用一个新的 viralenv 重新开始，并且您的项目文件保持安全。

另一个好处是，您的几个项目可以使用相同的 viralenv，所以如果您有很多依赖项，则不必反复执行相同的安装。

$ cd /foobar
$ source ../virtualenvs/foobar/bin/activate
$ python
>>> import mypackage2
>>>

对于那些经常需要设置和关闭 viralenvs 的用户来说，查看 viralenvwrapper 是有意义的。

http://pypi.python.org/pypi/virtualenvwrapper

使用虚拟包装器你可以

* create and delete virtual environments


* organize virtual environments in a central place


* easily switch between environments

在处理项目“ foo”和“ bar”时，你不必再担心你的 Virtual alenvs 在哪里:

  /foo
/mypackage1
__init__.py
/bar
/mypackage2
__init__.py

这就是你如何开始“ foo”项目的工作:

$ cd foo
$ workon
bar
foo
$ workon foo
(foo)$ python
>>> import mypackage1
>>>

然后，切换到项目“酒吧”就像这样简单:

$ cd ../bar
$ workon bar
(bar)$ python
>>> import mypackage2
>>>

Pretty neat, isn't it?

小开

如果您给您的项目一个 setup.py，pip 可以直接从版本控制导入它。

Do something like this:

$ virtualenv --no-site-packages myproject
$ . myproject/bin/activate
$ easy_install pip
$ pip install -e hg+http://bitbucket.org/owner/myproject#egg=proj

-e将把项目放在 myproject/src中，但是将它链接到 myproject/lib/pythonX.X/site-packages/，因此您所做的任何更改都将立即在从本地 site-packages导入的模块中被拾取。#egg位告诉 pip 您想给它为您创建的 egg 包取什么名字。

如果不使用 --no-site-packages，请注意指定您希望 pip 使用 -E选项安装到 viralenv 中

小开
最佳答案

virtualenv提供了一个 python 解释器实例，而不是一个应用程序实例。您通常不会在包含系统默认 Python 的目录中创建应用程序文件，同样也不需要将应用程序定位在 viralenv 目录中。

例如，您可能有一个项目，其中有多个应用程序使用相同的 viralenv。或者，您可能正在使用一个 Virtual alenv 测试一个应用程序，稍后将使用系统 Python 部署该应用程序。或者，您可能正在打包一个独立的应用程序，在这个应用程序中，将 viralenv 目录放在应用程序目录本身的某个位置可能是有意义的。

所以，总的来说，我不认为这个问题有一个正确的答案。而且，virtualenv的一个好处是它支持许多不同的用例: 不需要只有一种正确的方法。

小开

因为 viralenv 不可重定位，在我看来，将项目文件放在 viralenv 目录中是不好的做法。Virtual alenv 本身是一个生成的开发/部署工件(有点像。Pyc 文件) ，而不是项目的一部分; 应该很容易将其删除并随时重新创建，或者在新的部署主机上创建一个新的，等等。

Many people in fact use 虚拟包装器, which removes the actual virtualenvs from your awareness almost completely, placing them all side-by-side in $HOME/.virtualenvs by default.


提交答案