Question

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

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

创建此环境后，将自己放置在哪里：

python文件？
静态文件（图片/等）？
“自定义”套餐，例如在网上提供但在奶酪店中找不到的套餐？

与virtualenv目录有关吗？

（假设我已经知道where the virtualenv directories themselves should go。）

Answer 1

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

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

因此，总的来说，我认为这个问题没有一个正确的答案。而且，关于virtualenv的一个好处是它支持许多不同的用例：不需要一个正确的方法。

Answer 2

如果您经常只有几个项目，那么没有什么可以阻止您为每个项目创建一个新的virtualenv，并将您的软件包放在里面：

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

这种方法的优点是您始终可以确保找到属于项目内部的激活脚本。

$ 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
>>>

对于经常需要设置和拆除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

这就是你开始研究项目“foo”的方法：

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

然后切换到项目“bar”就像这样简单：

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

非常整洁，不是吗？

Answer 3

因为virtualenvs不可重定位，我认为将项目文件放在virtualenv目录中是不好的做法。 virtualenv本身是一个生成的开发/部署工件（有点像.pyc文件），不是项目的一部分;它应该很容易被吹掉并随时重新创建它，或者在新的部署主机上创建一个新的等等。

许多人实际上使用virtualenvwrapper，这几乎完全消除了你的意识中的真实虚拟现象，默认情况下将它们并排放在$ HOME / .virtualenvs中。

Answer 4

如果您为项目提供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/相关联，因此您所做的任何更改都会立即从您的本地{{{{}} { 1}}。 site-packages位告诉pip你要为它创建的egg包给你什么名字。

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

自定义代码在virtualenv中的位置如何？

4 个答案: