这种方法对Django的多个设置文件是否合理？

Question

问题

我对多个Django settings.py文件的处理方式是否合理（透明，安全等）？

我的方法

我有settings.py和settings_local.py。 settings.py受版本控制，settings_local.py不受版本控制。在settings.py结束时，它会尝试导入settings_local.py（如果可用）。

我对这种方法的理论是，我可以将我的默认/安全设置保留在settings.py下，然后简单地推送到生产部署。部署时，settings_local.py将不存在，并且不使用其仅限本地的设置。但是，在本地工作settings_local.py时，会使用其仅限本地的设置。

settings.py

DEBUG = False
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
)
# other settings...

try:
    from settings_local import *
except ImportError:
   pass

settings_local.py

from settings import *

DEBUG = True
MIDDLEWARE_CLASSES += (
    'debug_toolbar.middleware.DebugToolbarMiddleware',
)
# other settings...

我对这种方法的关注是它们都导入了另一种方法。我不认为这有资格作为循环导入，但作为一个指标，在不同的情况下，人们会考虑合并这些文件。

settings_local.py导入settings.py的原因是我可以在遵守DRY原则的同时添加已定义的变量，例如在没有完全重新定义的情况下向MIDDLEWARE_CLASSES添加新条目。

谢谢！

---

解决方案

最终，我放弃了上述方法。对我来说，尝试解决这个问题是一个有趣且信息丰富的过程，然而，我的合并方法有太多缺点。

对于将来发现这一点的人来说，最合适的方法很可能是wiki page on this topic中概述的解决方案之一，正如@DrTyrsa和@Mark Lavin所指出的那样，谢谢！

Answer 1

虽然这是一种常见的方法，但这不是一个好方法。我过去曾使用过这种配置，因此放弃了它。当您有多个开发人员一起工作或部署到多个环境（即分段和生产）时，问题就出现了。您可以选择

1. 制作settings.py制作设置。然后，每个开发人员必须覆盖设置以设置其本地环境（数据库设置，DEBUG=True，添加debug_toolbar等）。由于这不是源代码控制，它是重复的工作，并导致“它在我的机器上工作”的各种问题。
2. 制作settings.py开发设置。现在，您在local_settings.py中拥有有意义的生产配置部分，不在源代码管理中。这使部署变得混乱。显然，您不希望将敏感信息放在源代码管理中。

添加暂存环境会让情况变得更糟。我更喜欢SplitSettings wiki中描述的Simple Package Organization for Environments。