这种处理 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。