django食谱 2.2.1

设置

以下是一个示例，展示了如何使用最常见的设置来使用此食谱。

[buildout]
show-picked-versions = true
parts =
    django
eggs =
    yourproject
    gunicorn
develop = .
# ^^^ Assumption: the current directory is where you develop 'yourproject'.
versions = versions

[versions]
Django = 1.8.2
gunicorn = 19.3.0

[django]
recipe = djangorecipe
settings = development
eggs = ${buildout:eggs}
project = yourproject
test = yourproject
scripts-with-settings = gunicorn
# ^^^ This line generates a bin/gunicorn-with-settings script with
# the correct django environment settings variable already set.

早期版本的djangorecipe曾为您创建项目结构，如果您需要的话。现在Django本身就能生成良好的项目结构。只需运行 bin/django startproject <项目名称> 即可。创建的主要目录就是您放置buildout以及可能需要放置 setup.py 的目录。

startproject会为您创建一个 manage.py 脚本。您可以将其删除，因为djangorecipe创建的 bin/django 脚本是它的（几乎完全相同）替代品。

有关更多信息，请参阅Django的文档 startproject。

您还可以查看 cookiecutter。

支持的选项

该食谱支持以下选项。

project

此选项设置项目的名称。

settings

您可以使用此选项设置要使用的设置文件名称。如果您想要与开发设置不同的生产设置，这非常有用。默认为 development。

test

如果您想在bin文件夹中的脚本运行特定一组应用的所有测试，则可以使用此选项。将此设置为要测试的应用标签列表。通常建议您使用此选项并将其设置为项目名称。

scripts-with-settings

将脚本名称添加到此处（如‘gunicorn’）会创建一个带有‘-with-settings’后缀的重复脚本（例如： bin/gunicorn-with-settings）。它们会设置设置环境变量。目前，这主要用于gunicorn，它不能再在django进程中运行。因此，脚本必须已经传递了正确的设置环境变量。

注意：脚本所在的包必须位于您的部分的“eggs”选项中。因此，如果您使用gunicorn，请将其添加到其中（或将其添加为项目的依赖项）。

eggs

与大多数buildout食谱一样，您可以/必须传递要在此处提供的egg（Python包）。通常，您会在 [buildout] 部分中有一个列表，并通过说 ${buildout:eggs} 来重用它。

coverage

如果您设置 coverage = true，则在Django启动之前，bin/test 将开始记录覆盖率。必须可导入 coverage 库。有关更多信息，请参阅下面的额外覆盖率说明。

以下选项主要用于旧项目或特殊案例。

dotted-settings-path

使用此选项指定要使用的自定义设置路径。默认情况下，project 和 settings 选项值将连接起来，例如 myproject.development。 dotted-settings-path = somewhere.else.production 允许您自定义它。

extra-paths

此处指定的所有路径都将用于扩展默认的Python路径，以用于 bin/* 脚本。如果您有一些没有适当 setup.py 的代码，请使用此选项。

control-script

在bin文件夹中创建的脚本名称。此脚本相当于Django通常创建的 manage.py。默认情况下，它使用节名称（[ ] 之间的部分）。传统上，该部分被称为 [django]。

initialization

指定一些要插入到 control-script 中的Python初始化代码。此功能非常有限。特别是请注意，从提供的代码中删除了前导空白。

wsgi

当此设置为true时，在bin文件夹中会生成一个额外的脚本。这主要在部署Apache的mod_wsgi时有用。脚本名称与控制脚本相同，但后面追加.wsgi。所以通常会是bin/django.wsgi。

wsig脚本

如果需要覆盖上述脚本的名称，请使用此选项。

deploy_script_extra

在wsgi部署脚本中，有时需要将应用程序包装在云服务提供商的自定义包装器中。此设置允许在wsgi脚本末尾追加额外内容。例如，application = some_extra_wrapper(application)。上述对初始化的限制也适用于此处。

testrunner

这是将要创建的testrunner的名称。默认为test。

覆盖率说明

从django 1.7开始，不再可以使用自定义测试运行器（如django-nose）来启用覆盖率自动运行测试。新的应用程序初始化机制已经在调用测试运行器之前加载了你的models.py，例如。因此，你的models.py将显示为大量未测试。

使用coverage = true，bin/test在调用django之前开始记录覆盖率。它还会打印报告并导出xml结果（例如，在Jenkins中记录测试结果）和html结果。

在幕后，true被翻译为默认值report xml_report html_report。这些由空格分隔的函数名称将依次在覆盖率实例上调用。请参阅覆盖率API文档以获取可用的函数。如果你只需要快速报告和xml输出，可以将coverage = report xml_report。

请注意，你不能向这些函数传递选项，例如html输出位置。为此，在buildout.cfg旁边添加一个.coveragerc。请参阅覆盖率配置文件文档。这里有一个示例

[run]
omit =
    */migrations/*
    *settings.py
source = your_app

[report]
show_missing = true

[html]
directory = htmlcov

[xml]
output = coverage.xml

mod_wsgi的示例配置

如果你想使用mod_wsgi部署项目，可以将此示例作为起点

<Directory /path/to/buildout>
     Order deny,allow
     Allow from all
</Directory>
<VirtualHost 1.2.3.4:80>
     ServerName      my.rocking.server
     CustomLog       /var/log/apache2/my.rocking.server/access.log combined
     ErrorLog        /var/log/apache2/my.rocking.server/error.log
     WSGIScriptAlias / /path/to/buildout/bin/django.wsgi
</VirtualHost>

特殊情况：当多个wsgi脚本组合在Apache的单个虚拟主机实例中时，存在一个问题。这是由于Django使用环境变量DJANGO_SETTINGS_MODULE。此变量在第一个wsgi脚本加载时设置一次。其余的wsgi脚本将失败，因为它们需要不同的设置模块。然而，环境变量DJANGO_SETTINGS_MODULE只设置一次。可以像下面这样使用添加到djangorecipe中的新初始化选项来解决这个问题

[django]
settings = acceptance
initialization =
    import os
    os.environ['DJANGO_SETTINGS_MODULE'] = '${django:project}.${django:settings}'

为PyDev生成控制脚本

在PyDev中运行Django并启用自动重新加载需要添加一小段代码

import pydevd
pydevd.patch_django_autoreload(patch_remote_debugger=False, patch_show_console=True)

在manage.py模块（或在这种情况下是生成的控制脚本，通常是bin/django）中，在if __name__ == “__main__”:之前运行Django。以下示例buildout生成了两个控制脚本：一个用于命令行使用，一个用于PyDev，使用配方中的初始化选项，添加了所需的代码片段

[buildout]
parts = django pydev
eggs =
    mock

[django]
recipe = djangorecipe
eggs = ${buildout:eggs}
project = dummyshop

[pydev]
<= django
initialization =
    import pydevd
    pydevd.patch_django_autoreload(patch_remote_debugger=False, patch_show_console=True)

django-configurations的示例用法

django-configurations (http://django-configurations.readthedocs.org/en/latest/) 是一个帮助您将Django设置组织到类中的应用程序。使用它需要修改manage.py文件。这可以通过使用配方的初始化选项轻松完成

[buildout]
parts = django
eggs =
    hashlib

[django]
recipe = djangorecipe
eggs = ${buildout:eggs}
project = myproject
initialization =
    # Patch the manage file for django-configurations
    import os
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')
    os.environ.setdefault('DJANGO_CONFIGURATION', 'Development')
    from configurations.management import execute_from_command_line
    import django
    django.core.management.execute_from_command_line = execute_from_command_line

2.2.1 (2016-06-29)

• 2.2版本修复bug：在bin/test中缺少了一个选项的引号。[reinout]

2.2 (2016-06-29)

• 添加了可选的coverage选项。将其设置为true将自动在您的django测试周围运行覆盖率。如果您曾经使用过像django-nose这样的测试运行器来自动运行覆盖率，则需要此功能。从django 1.7开始，这不再工作。有了新的“coverage”选项，bin/test会为您完成。[reinout]

• 自动化测试（travis-ci.org）现在使用django 1.4、1.8和1.9进行测试。以及pypi、python 2.7和python 3.4。[reinout]

2.1.2 (2015-10-21)

• 修复了文档中的bug：readme提到了script-with-settings而不是scripts-with-settings（注意script后面的缺失s）。正确的是script-with-settings。[tzicatl]

2.1.1 (2015-06-15)

• 修复了bug：script-entrypoints入口点查找现在实际上可以工作。

2.1 (2015-06-15)

• 将script-entrypoints选项重命名为scripts-with-settings。它接受其他情况下会生成的脚本名称（如gunicorn），并生成一个重复的脚本，名称为bin/gunicorn-with-settings。

  技术说明：这取决于脚本是否为setuptools的“console_script entrypoint”脚本。

2.0 (2015-06-10)

• 移除了项目生成。以前，djangorecipe会根据模板为您生成一个目录，但现在Django自带的模板已经足够好了。特别是：它现在会为您的项目生成一个子目录。只需运行bin/django startproject <projectname>。

  有关更多信息，请参阅Django的文档 startproject。

  您还可以查看 cookiecutter。

  这也意味着projectegg选项现在已弃用，不再需要。

• 我们现在针对django 1.7和1.8。django 1.4仍然可以工作，（除了那个没有很好的startproject命令）。

• Gunicorn不包含django manage.py集成，因此bin/django run_gunicorn不再工作。如果您在配置中添加script-entrypoints = gunicorn，我们将生成一个与bin/gunicorn相同，但环境设置正确的bin/django_env_gunicorn脚本。注意：在2.1中已重命名为“scripts-with-settings”。

  这样，您就可以使用项目中的wsgi.py脚本（如果需要，可以从django文档中复制它），使用bin/django_env_gunicorn yourproject/wsgi.py来运行，就像建议的那样。这样您就可以根据您的喜好调整wsgi文件，并用gunicorn运行它。

  对于其他wsgi运行程序（或您想使用正确环境设置的程序），您可以将完整的入口点添加到script-entrypoints中，例如，对于gunicorn，完整的行将是script-entrypoints = gunicorn=gunicorn.app.wsgiapp:run。在相关包的setup.py中查找正确的入口点。

  Django的1.8 wsgi.py文件看起来像这样，请参阅https://docs.django.ac.cn/en/1.8/howto/deployment/wsgi/

  import os
  
  from django.core.wsgi import get_wsgi_application
  
  os.environ.setdefault("DJANGO_SETTINGS_MODULE", "yourproject.settings")
  
  application = get_wsgi_application()

• wsgilog选项已被弃用，旧的apache mod_wsgi脚本已经很长时间没有使用了。

• 移除了旧的pth选项，以前用于pinax。Pinax已经使用了很长时间的正确的python包，因此不再需要。

1.11 (2014-11-21)

• dotted-settings-path选项以前只在管理脚本中使用。现在它也被用于生成的wsgi文件和测试脚本。

1.10 (2014-06-16)

• 添加了dotted-settings-path选项。当您想为manage.main()命令指定自定义设置路径时很有用。

• 将 deploy_script_extra（带下划线）重命名为 deploy-script-extra（带破折号），以与其他选项保持一致。如果发现下划线版本，将引发异常。

1.9 (2014-05-27)

• bin/test 现在将命令行参数传递给底层管理命令。以前，只会执行相当于 manage.py test list_of_apps 的操作。现在，命令行参数将作为应用列表之后的参数原样传递。

• 添加了 deploy_script_extra 选项。它被附加到 wsgi 脚本中。例如，对于需要将 wsgi 应用对象包装在自定义调用中的云主机来说，这很有用。

1.8 (2014-05-27)

• 现在支持 buildout 的相对路径设置。

1.7 (2013-12-11)

• 添加了更改 wsgi 脚本名称的选项。感谢 hedleyroos（修复了 pull #74）。

1.6 (2013-10-28)

• Djangorecipe 现在可以与 django 1.6 一起工作。

• 在 Django 1.4、1.5 和 1.6 上进行了测试。现在不再支持 1.4 以下版本。也测试了 Python 2.6/2.7、3.2/3.3。

• 仅支持 buildout 2。

• 删除了生成 fastcgi 脚本。您可以轻松地作为 bin/django runfcgi 运行它，并且在 Django 1.7 中它也将被弃用。

1.5 (2013-01-25)

• 删除了对与运行 buildout 所使用的 Python 版本不同的支持。以前，您可以使用 2.6 运行 buildout，但让 Django 使用 2.7。zc.buildout 2.0 不再允许这样做，所以我们也将它删除了。

1.4 (2013-01-15)

• 添加了对初始化代码的支持。感谢 anshumanb 和 jjmurre。(Closes #58)

1.3 (2012-09-07)

• 删除了 Django 1.4 中的弃用警告。修复了 #49，感谢 Shagi。

• 为与 mr.developer 一起使用添加了文档。感谢 shagi (closes issue #45)

• 添加了对 Travis 的支持。

1.2.1 (2012-05-15)

• 修复了损坏的 1.2 版本（由于最近的 txt-to-rst 重命名操作而缺少 *.rst 文件）。

1.2 (2012-05-14)

• 从配方中删除了位置路径。感谢 bleskes (修复了问题 #50)。

1.1.2

• 添加了正确的弃用警告 URL。

1.1.1

• 修复了 Python3 Trove 分类器。

1.1

• 支持 Python3。

• 将 buildout 和测试更改为在 nose 下运行测试。

• 删除了一些旧版本 0.99 之前的 unittest，它们处理下载支持。

1.0

• 这是一个具有真实 1.0 版本的稳定版本。

• 使 djangorecipe 更符合 pep08。

0.99

• Djangorecipe 现在依赖于 Django。弃用了 version = 语句。在 [versions] 部分指定 django 版本。如果您需要使用 svn/git/hg 仓库，请通过 mr.developer 安装 django。对于其他用途，如果不想升级，请将 djangorecipe 版本指定为 0.23.1。感谢 Reinout van Rees 在此版本中的帮助。

• 删除了子版本控制和下载支持。

0.23.1

• 添加了缺失的 import os。

0.23

• 支持 django 1.2 和 django 1.3 的设置/urls 模板。如果版本不是 1.2，则默认为 1.3。

0.22

• 添加了对包含空格的 svn URL 的支持。感谢 Brad103 (修复了 #537718)。

• 更新了代码和 buildout 以使用最新的 zc.recipe.egg、zc.recipe.testrunner 和 python-dateutil。

0.21

• 现在为 django 1.1 或更高版本配置了管理 URL。感谢 Sam Charrington (修复了 #672220)。

• 更新了 bootstrap.py（修复了 #501954）。

0.20

• 该配方现在在安装期间让 setuptools 知道 django 包。这关闭了 #397864。感谢 Daniel Bruce 和 Dan Fairs 提供的补丁。

• 修复了 #451065，该补丁修复了 WSGI 日志文件选项的问题。

• 添加了配置更多 FCGI 相关设置的选项。感谢 Vasily Sulatskov 提供的补丁。

0.19.2

• 当选项更改时，现在将正确地删除生成的 WSGI & FCGI 脚本（修复了 #328182）。感谢 Horst Gutmann 提供的补丁。

• 当依赖关系更改时，现在将更新脚本。这修复了 #44658，感谢 Paul Carduner 提供的补丁。

0.19.1

• 应用了 WSGI 脚本生成更改的修复。上一个版本没有正常工作。

0.19

• 当再次运行非最新设置时，食谱将不再更新Subversion检出。感谢vinilios提供的补丁。

• WSGI和FCGI脚本现在使用Buildout自己的系统生成。这使得它们在路径设置方面与生成的管理脚本更相似。感谢Jannis Leidel提供的补丁。

0.18

• 来自egg和extra-paths的路径现在优先于默认系统路径（解决了#370420）。感谢Horst Gutmann提供的补丁。

• 生成的WSGI脚本现在如果存在，将使用python选项。这解决了#361695。

0.17.4

• 修复了非详细模式运行时的问题（解决了#375151）。

0.17.3

• 移除了对setuptools_bzr的依赖，因为它似乎没有像预期的那样工作。

0.17.2

• 将下载代码更改为使用urllib2。这应该使其在代理后面工作（解决了#362822）。感谢pauld提供的补丁。

0.17.1

• 修复了新的WSGI日志选项问题#348797。感谢Bertrand Mathieu提供的补丁。

• 如果“wsgilog”未设置，则禁用生成WSGI日志，感谢Jacob Kaplan-Moss提供的补丁。

• 更新了buildout.cfg和.bzrignore，感谢Jacob Kaplan-Moss。

0.17

• 添加了一个选项，可以指定从WSGI脚本输出重定向的日志文件。感谢Guido Wesdorp提供的补丁。

0.16

• 现在支持Subversion别名（类似于svn+mystuff://myjunk）。感谢Remco提供的补丁。

0.15.2

• 更新将pth-files查找器从__init__方法移动到安装方法，以便在buildout顺序中运行，否则它会在可能尚不存在的目录中查找pth文件。感谢Chris Shenton对其原始补丁的更新。

0.15.1

• 更新以更好地记录之前添加的pth-files选项。

0.15

• 添加了“pth-files”选项，可以从site .pth文件将库添加到extra-paths。感谢Chris Shenton提供的补丁。

0.14

• 食谱现在支持创建FCGI脚本。感谢Jannis Leidel提供的补丁。

• 首次下载Django食谱时，食谱现在正确报告其下载的url。

0.13

• 在subversion url中指定用户名现在工作。确定修订版本的代码已更新。这解决了问题#274004。感谢Remco提供的补丁。

• 更新了创建新项目的模板。现在在生成其urls.py文件时使用当前的管理系统。这解决了问题#276255。感谢Roland提供的补丁。

0.12.1

• 由于CHANGES.txt缺失，重新上传

0.12

• 食谱不再执行subversion以确定是否应使用subversion下载版本。这解决了问题#271145。感谢Kapil Thangavelu提供的补丁。

• 将pythonpath选项更改为extra-paths。这使得食谱与其他食谱更一致（见问题#270908）。

0.11

• 通过确保始终调用更新方法来解决更新问题（#250811），因为在前一个版本中，食谱会将一个随机的秘密（如果未指定）写入选项以用于模板。Buildout将其视为选项更改，因此始终决定卸载并安装。

• 当同时指定projectegg和wsgi=True时，生成的wsgi文件中没有正确的设置文件。这个问题通过Dan Fairs的补丁已修复。

• 食谱现在有日志记录。所有print语句都已替换，并添加了一些额外的日志调用。这使得关于长时间运行的任务的食谱更具信息性。感谢erny提供的补丁，来自问题#260628。

0.10

• 食谱不再期望发布tarball的顶级目录名称与版本号一致。这解决了问题#260097。感谢erny报告此问题和提出解决方案。

• 在重新运行buildout时，现在保留svn checkout的修订版固定。这解决了问题#250811。感谢Remco报告此问题。

• 添加了一个选项，用于指定一个鸡蛋作为项目。这将禁用创建基本项目结构的代码。感谢Dan Fairs为issue #252647提供的补丁。

0.9.1

• 修复了由于缺少manifest文件而损坏的上一版本。

0.9

• 设置选项已修复，以便支持任意深度的设置路径（例如；conf.customer.development）。

• 版本参数现在接受完整的svn url。您可以使用它来获取分支或使用标准的svn @语法将任何url固定到特定修订版本。

• WSGI脚本不再设置为仅由运行buildout的用户可执行和可读。这避免了部署问题。