如何分发Django应用程序及其特定设置？

Question

我遇到了有关应用特定设置的问题。

我有两个Django项目，P1和P2，每个项目都在自己的虚拟环境中运行。 P2使用P1的应用程序中的一些模型，因此我使用add2virtualenv（感谢virtualenvwrapper）来处理依赖关系。

问题在于，其中一些P1应用依赖于custom settings（仅位于p1/project/settings.py，没有任何花哨so far），这显然会严重影响P2的执行。

例如，当我运行P2的测试时：

$ ./p2/manage.py test

Traceback (most recent call last):
  File "./manage.py", line 11, in <module>
    execute_from_command_line(sys.argv)
  [...]
AttributeError: 'Settings' object has no attribute 'SOME_P1_APP_CUSTOM_SETTING'

我该怎么处理？它是否被设计破坏，或者Django是否提供优雅的处理应用程序特定设置的分布？ 我想避免在每个需要它们的项目中复制/粘贴这些设置。

Answer 1

如果您有两个应用程序，一个是后端，另一个是使用它的服务，我建议您在测试使用它的服务时模拟后端。这就是问题的关键：你正在尝试为Thing A运行测试，这也需要运行事物B，并且Django测试服务器并没有真正满足这个需求（这是当你执行测试时，在表面下运行的是什么。

所以，是的，你需要在测试服务时伪造后端（反之亦然）。

有很多方法可以做到这一点，包括使用Python＆＃39; mock＆＃39;库来模拟其他应用程序的API（或者更具体地说，模拟MyService中与MyBackend对话的函数）并返回符合您尝试测试的任何行为的数据对象。这些假响应可能基于从其他应用程序转储的JSON加载的实际测试装置，可能。

为了让生活更轻松，您还可以在后端仓库中编写一些测试，以确保模拟后端数据的架构实际上与真实后端的架构相匹配，这样可以避免在一个或两个应用程序发生更改时出现回归。如果您确实对该数据使用了fixture，那么将该模拟数据存储在一个中间存储库中（然后将其作为代码库的外部依赖项包含在内）将是确保它们可用于两个代码库而无需在测试期间要安装并运行的实际其他代码库。

Answer 2

我会使用三个不同的设置文件：两个项目使用的公共文件和其他两个设置文件（每个项目用于项目），它们导入公共文件并使用适当的属性覆盖或扩展它。

通常情况下，将dev或prod环境的设置文件分开并导入common一个设置。您可以在django-skel项目中看到示例。

在这两个设置的每一个中，您都可以从公共中导入所有内容：

from common import *

Answer 3

1。 一个快速且可行的解决方案是从P1过滤掉所有设置，这些是P2执行所需的设置并将其置于common.py

在P2中，要么从P1导入common.py

#### P2/settings.py ####
from p1.commons import *

或

将common.py设置文件复制到P2并导入。

#### P2/settings.py ####
from commons import *

2。 如果这个问题只有Test runner 。那么我建议你创建一个 test_settings.py ，它将从P2中的settings.py导入：

#### P2/test_settings.py ####
from settings import *

### Put here all extra settings required for the P2's test execution

并使用它来运行Test，使用--settings选项，例如。

.p2/manage.py --setting=test_settings test

结构良好的设置文件结构始终是非bug应用程序的首选。 您可以按照 django-skel 更深入地了解良好的设置结构

Answer 4

我在网上找到的可能解决方案：

1. 始终使用默认值调用getattr()来访问设置 Pro ：简单，优雅，听起来像是一种很好的做法 Con ：对默认值没有意义的设置（如API密钥）没有帮助。
2. 使用第三方解决方案，例如django-appconf或django-appsettings Pro ：让您远离潜水问题。 Con ：有些人可能会发现它非常压倒性。
3. 将特定的额外设置__init__.py文件放在应用根目录中，如Chris Burnor's post中建议的那样 Pro ：清楚地突出显示您应用的设置，便于查找和发货 Con ：如果使用模板系统，可能会部署到地狱;也可能有点误导，因为它不是一个众所周知的做法（据我所知）。
4. 介绍一些关于设置处理的逻辑，例如this snippet Pro ：完成工作。
   Con ：逻辑没有任何关系。