自定义代码在virtualenv中的位置？
在使用virtualenv时应遵循什么样的目录结构？ 例如，如果我正在构build一个WSGI应用程序并创build了一个名为foobar的virtualenv，我将从如下目录结构开始：
/foobar /bin {activate, activate.py, easy_install, python} /include {python2.6/...} /lib {python2.6/...}
一旦创build了这个环境，他们自己的位置在哪里：
- python文件？
- 静态文件（图像/等）？
- “定制”软件包，例如在网上可以find但是在奶酪店里找不到的那些软件包？
关于virtualenv目录？
（假设我已经知道virtualenv目录本身应该去哪里了 。）
virtualenv提供了一个python解释器实例，而不是一个应用程序实例。 您通常不会在包含系统默认Python的目录中创build您的应用程序文件，同样也不需要在virtualenv目录中find您的应用程序。
例如，你可能有一个项目，你有多个应用程序使用相同的virtualenv。 或者，您可能正在使用virtualenvtesting应用程序，稍后将使用系统Python进行部署。 或者，您可能正在打包一个独立的应用程序，将virtualenv目录置于应用程序目录本身的某个位置，这样做可能是有意义的。
所以一般来说，我不认为这个问题有一个正确的答案。 而virtualenv一个好处就是它支持许多不同的用例：不需要是一个正确的方法。
如果你每隔一段时间只有几个项目，没有什么能阻止你为每个项目创build一个新的virtualenv，并把你的包放在里面：
/foobar /bin {activate, activate.py, easy_install, python} /include {python2.6/...} /lib {python2.6/...} /mypackage1 __init__.py /mypackage2 __init__.py
这种方法的优点是你总是可以findfind属于项目里面的激活脚本。
$ cd /foobar $ source bin/activate $ python >>> import mypackage1 >>>
如果你决定组织一些，你应该考虑把你所有的virtualenvs放在一个文件夹中，并且在你正在工作的项目之后命名它们。
/virtualenvs /foobar /bin {activate, activate.py, easy_install, python} /include {python2.6/...} /lib {python2.6/...} /foobar /mypackage1 __init__.py /mypackage2 __init__.py
这样，当出现问题时，您总是可以重新开始一个新的virtualenv，并且您的项目文件保持安全。
另一个优点是你的几个项目可以使用相同的virtualenv，所以如果你有很多的依赖关系，你不必一遍又一遍地重复安装。
$ cd /foobar $ source ../virtualenvs/foobar/bin/activate $ python >>> import mypackage2 >>>
对于那些经常需要build立和拆卸virtualenvs的用户来说，看看virtualenvwrapper是有意义的。
http://pypi.python.org/pypi/virtualenvwrapper
用virtualenvwrapper你可以
* create and delete virtual environments * organize virtual environments in a central place * easily switch between environments
在“foo”和“bar”项目上工作时，你不必担心你的virtualenvs在哪里：
/foo /mypackage1 __init__.py /bar /mypackage2 __init__.py
这就是你开始在项目“富”上工作的方式：
$ cd foo $ workon bar foo $ workon foo (foo)$ python >>> import mypackage1 >>>
然后切换到项目“栏”是这样简单：
$ cd ../bar $ workon bar (bar)$ python >>> import mypackage2 >>>
漂亮整洁，不是吗？
由于virtualenvs不可重定位，在我看来，将您的项目文件放置在virtualenv目录中是不好的做法。 virtualenv本身是一个生成的开发/部署工件（有点像.pyc文件），而不是项目的一部分; 应该很容易把它吹走并随时重新创build，或者在新的部署主机上创build一个新的。
许多人实际上使用了virtualenvwrapper ，它几乎完全从你的意识中删除了真正的virtualenvs，默认情况下它们并排放置在$ HOME / .virtualenvs中。
如果你给你的项目一个setup.py ，pip可以从版本控制直接导入它。
做这样的事情：
$ 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你要给它创build的蛋包的名字。
如果您不使用--no-site-packages ，请小心指定您希望使用-E选项将pip安装到virtualenv中
