问题:自定义代码在virtualenv中的什么位置?

使用时应该遵循哪种目录结构virtualenv?例如,如果我正在构建WSGI应用程序并创建了一个名为virtualenv的虚拟环境,那么foobar我将从以下目录结构开始:

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

创建此环境后,将在哪里放置自己的环境:

  • python文件?
  • 静态文件(图像/等)?
  • “自定义”程序包,例如在线提供但在奶酪店中找不到的程序包?

关于virtualenv目录?

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

What sort of directory structure should one follow when using virtualenv? For instance, if I were building a WSGI application and created a virtualenv called foobar I would start with a directory structure like:

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

Once this environment is created, where would one place their own:

  • python files?
  • static files (images/etc)?
  • “custom” packages, such as those available online but not found in the cheese-shop?

in relation to the virtualenv directories?

(Assume I already know where the virtualenv directories themselves should go.)


回答 0

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

例如,您可能有一个项目,其中有多个使用同一virtualenv的应用程序。或者,您可能正在使用virtualenv测试应用程序,该应用程序随后将与系统Python一起部署。或者,您可能正在打包一个独立的应用程序,在该应用程序中,将virtualenv目录放置在应用程序目录本身内的某个位置可能很有意义。

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

virtualenv provides a python interpreter instance, not an application instance. You wouldn’t normally create your application files within the directories containing a system’s default Python, likewise there’s no requirement to locate your application within a virtualenv directory.

For example, you might have a project where you have multiple applications using the same virtualenv. Or, you may be testing an application with a virtualenv that will later be deployed with a system Python. Or, you may be packaging up a standalone app where it might make sense to have the virtualenv directory located somewhere within the app directory itself.

So, in general, I don’t think there is one right answer to the question. And, a good thing about virtualenv is that it supports many different use cases: there doesn’t need to be one right way.


回答 1

如果您经常只有几个项目,那么没有什么可以阻止您为每个项目创建一个新的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
>>>

很整洁,不是吗?

If you only have a few projects every so often, nothing stops you from creating a new virtualenv for each one, and putting your packages right inside:

/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

This way you can always start over with a new virtualenv when things go wrong, and your project files stay safe.

Another advantage is that several of your projects can use the same virtualenv, so you don’t have to do the same installation over and over if you have a lot of dependencies.

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

For users that regularly have to set up and tear down virtualenvs it would make sense to look at virtualenvwrapper.

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

With virtualenvwrapper you can

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

You no more have to worry about where your virtualenvs are when working on the projects “foo” and “bar”:

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

This is how you start working on project “foo”:

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

Then switching to project “bar” is as simple as this:

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

Pretty neat, isn’t it?


回答 2

因为virtualenvs不可重定位,所以我认为将项目文件放在virtualenv目录中是不明智的做法。virtualenv本身是一个生成的开发/部署工件(有点像.pyc文件),而不是项目的一部分;应该很容易将其吹散并随时重新创建,或者在新的部署主机上创建一个新的,等等。

实际上,许多人都使用virtualenvwrapper,它几乎完全从您的意识中删除了实际的virtualenvs,默认情况下将它们全部并排放置在$ HOME / .virtualenvs中。

Because virtualenvs are not relocatable, in my opinion it is bad practice to place your project files inside a virtualenv directory. The virtualenv itself is a generated development/deployment artifact (sort of like a .pyc file), not part of the project; it should be easy to blow it away and recreate it anytime, or create a new one on a new deploy host, etc.

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


回答 3

如果您为您的项目指定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您要给它为您创建的鸡蛋包装取什么名字。

如果您不使用--no-site-packages,请谨慎指定要使用-E选项将pip安装到virtualenv中

If you give your project a setup.py, pip can import it from version control directly.

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

The -e will put the project in myproject/src, but link it to myproject/lib/pythonX.X/site-packages/, so any changes you make will get picked up immediately in modules that import it from your local site-packages. The #egg bit tells pip what name you want to give to the egg package it creates for you.

If you don’t use --no-site-packages, be careful to specify that you want pip to install into the virtualenv with the -E option


声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。