Python 这种处理Django多设置文件的方法合理吗？ 问题:

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

我的方法 我有一个

settings.py

和一个

settings\u local.py

settings.py

受版本控制，而a

settings\u local.py

不受版本控制。在

settings.py

的末尾，如果可用，它将尝试导入

settings\u local.py

我对这种方法的理论是，我可以将默认/安全设置保留在

settings.py

下，然后直接推到生产环境中进行部署。在部署时，

设置\u local.py

将不存在，并且不使用其仅本地设置。但是，在本地工作时，会显示

设置\u local.py

，并且只使用其本地设置

设置.py 设置\u local.py 我对这种方法的担忧是，它们都引入了另一种方法。我不认为这是一个循环进口，但作为一个指标，在不同的情况下，人们会考虑合并这些文件。 之所以导入

settings\u local.py

imports

settings.py

，是因为我可以添加到已经定义的变量，同时遵守枯燥的原则，例如，在不完全重新定义的情况下向

MIDDLEWARE\u CLASSES

添加新条目

谢谢

---

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

---

对于将来发现这一点的人来说，最合适的方法很可能是本指南中概述的解决方案之一，正如@DrTyrsa和@Mark Lavin善意地指出的，谢谢

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

制作

settings.py

生产设置。然后，每个开发人员必须覆盖设置以设置其本地环境（DB设置，

DEBUG=True

，添加

DEBUG\u工具栏

，等等）。由于这不是源代码控制，它是重复的工作，并导致“它在我的机器上工作”之类的问题

进行

settings.py

开发设置。现在您在

local_settings.py

中有了有意义的生产配置，而不在源代码管理中。这使得部署变得混乱。显然，您不想将敏感信息放入源代码管理中

---

添加登台环境只会让情况变得更糟。我更喜欢SplitSettings wiki中描述的设置。

我通常做的是将本地设置设置为

settings.py

（不在版本控制中），然后在版本控制中设置

settings\u base.py

（实际上，还有一个

settings\u dev.py

和

settings\u server.py

，具有可用于跟踪的非敏感设置；这些设置从

settings\u base

导入）这避免了准循环导入，但这意味着在一个新的结帐时，您必须记住要从StutsSeDave**>设置，Py＜/Calp>进行“代码>回声”。在创建自己之前，您也可以查看。@道格尔，谢谢，我也会考虑这个方法。我的方法似乎符合我的项目和个人逻辑，但是，我非常愿意承认这不是一个好的方法。谢谢你的反馈，马克。我认为你是对的，我的方法不是一个好的解决方案。我学到了很多尝试，然而，这是最枯燥的解决方案（正如你所指出的）将使用现有的流行方法：）作为更新@Mark Lavin，我一直在使用您推荐的“环境的简单包组织”方法，它非常简单和透明。谢谢“环境的简单包组织”方法简单而有用，感谢您的回答。。

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

try:
    from settings_local import *
except ImportError:
   pass

from settings import *

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