这种 Django 多个设置文件的方法合理吗？

Question

问题

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

我的方法

我有一个settings.py和一个settings_local.py。settings.py受版本控制，asettings_local.py不受版本控制。最后settings.py它会尝试导入settings_local.py（如果可用）。

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

设置.py

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

try:
    from settings_local import *
except ImportError:
   pass

设置_本地.py

from settings import *

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

我对这种方法的担忧是它们都互相导入。我不认为这符合循环导入的条件，而是作为一个指标，表明在不同情况下人们会考虑合并这些文件。

settings_local.py导入的原因settings.py是这样我可以添加到已经定义的变量，同时遵守 DRY 原则，例如添加一个新条目MIDDLEWARE_CLASSES而不完全重新定义它。

谢谢！

---

解决方案

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

对于将来发现此问题的人们来说，最合适的方法可能是有关此主题的 wiki 页面中概述的解决方案之一，正如 @DrTyrsa 和 @Mark Lavin 善意指出的，谢谢！

Answer 1

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

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

添加暂存环境只会让情况变得更糟。我更喜欢SplitSettings wiki 中描述的环境的简单包组织。