5

问题

我对以下多个 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

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 页面中概述的解决方案之一，正如 @DrTyrsa 和 @Mark Lavin 所指出的那样，谢谢！

4

1 回答 1

5

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

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

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

于 2012-04-23T20:35:32.043 回答