大多数解决方案的问题是，您要么将本地设置应用在常用设置之前，要么应用在常用设置之后。

所以不可能覆盖

特定于env的设置定义了memcached池的地址，在主设置文件中，这个值用于配置缓存后端 特定环境的设置添加或删除应用程序/中间件到默认的

同时。

一种解决方案可以使用“ini”风格的配置文件和ConfigParser类实现。它支持多个文件、延迟字符串插值、默认值和许多其他优点。 一旦加载了许多文件，就可以加载更多的文件，它们的值将覆盖之前的文件(如果有的话)。

您可以加载一个或多个配置文件，这取决于计算机地址、环境变量，甚至是先前加载的配置文件中的值。然后只需使用解析后的值填充设置。

我成功使用的一个策略是:

Load a default defaults.ini file Check the machine name, and load all files which matched the reversed FQDN, from the shortest match to the longest match (so, I loaded net.ini, then net.domain.ini, then net.domain.webserver01.ini, each one possibly overriding values of the previous). This account also for developers' machines, so each one could set up its preferred database driver, etc. for local development Check if there is a "cluster name" declared, and in that case load cluster.cluster_name.ini, which can define things like database and cache IPs

举个例子，你可以定义一个“子域”值per-env，然后在默认设置中使用(hostname: %(subdomain).whatever.net)来定义django工作所需的所有必要的主机名和cookie。

这是我能得到的DRY，大多数(现有的)文件只有3或4个设置。除此之外，我还必须管理客户配置，所以存在一组额外的配置文件(包括数据库名称、用户和密码、分配的子域等)，每个客户一个或多个。

您可以根据需要将其扩展到低或高，只需在配置文件中放入您想要在每个环境中配置的键，一旦需要新的配置，将先前的值放在默认配置中，并在必要时覆盖它。

该系统已被证明是可靠的，并与版本控制工作良好。它已经被使用很长时间来管理两个独立的应用程序集群(每台机器上有15个或更多的django站点实例)，有超过50个客户，集群的大小和成员会根据系统管理员的情绪而变化……

对于我的大多数项目，我使用以下模式:

创建settings_base.py，其中存储所有环境的通用设置 每当我需要使用具有特定要求的新环境时，我都会创建新的设置文件(例如。Settings_local.py)，它继承settings_base.py的内容，并覆盖/添加适当的设置变量(从settings_base import *)

(要使用自定义设置文件运行manage.py，只需使用——settings命令option: manage.py <命令>——settings=settings_you_wish_to_use.py)

我对这个问题的解决方案在某种程度上也是这里已经提到的一些解决方案的混合:

我保留了一个名为local_settings.py的文件，其内容为USING_LOCAL = True在dev中，USING_LOCAL = False在prod中 在settings.py中，我对该文件进行导入以获得USING_LOCAL设置

然后我将所有与环境相关的设置都基于此:

DEBUG = USING_LOCAL
if USING_LOCAL:
    # dev database settings
else:
    # prod database settings

我更喜欢这样，而不是有两个单独的settings.py文件，我需要维护，因为我可以将我的设置结构化地保存在一个文件中，而不是将它们分布在几个文件中。就像这样，当我更新一个设置时，我不会忘记在两个环境中都这样做。

当然每种方法都有它的缺点，这种方法也不例外。这里的问题是，无论何时将更改推到生产环境中，我都不能覆盖local_settings.py文件，这意味着我不能盲目地复制所有文件，但这是我可以接受的。

我在django split-settings的帮助下管理我的配置。

它是默认设置的临时替换。它很简单，但可配置。并且不需要重构现有设置。

下面是一个小例子(文件示例/settings/__init__.py):

from split_settings.tools import optional, include
import os

if os.environ['DJANGO_SETTINGS_MODULE'] == 'example.settings':
    include(
        'components/default.py',
        'components/database.py',
        # This file may be missing:
        optional('local_settings.py'),

        scope=globals()
    )

就是这样。

更新

我写了一篇关于用django-split-sttings管理django设置的博文。看看吧!

不要使用settings.py，而是使用下面的布局:

.
└── settings/
    ├── __init__.py  <= not versioned
    ├── common.py
    ├── dev.py
    └── prod.py

py是您的大部分配置所在的位置。

py从common中导入所有内容，并覆盖它需要覆盖的内容:

from __future__ import absolute_import # optional, but I like it
from .common import *

# Production overrides
DEBUG = False
#...

类似地，dev.py从common.py导入所有内容，并覆盖它需要覆盖的内容。

最后，__init__.py是你决定加载哪些设置的地方，也是你存储秘密的地方(因此这个文件不应该被版本化):

from __future__ import absolute_import
from .prod import *  # or .dev if you want dev

##### DJANGO SECRETS
SECRET_KEY = '(3gd6shenud@&57...'
DATABASES['default']['PASSWORD'] = 'f9kGH...'

##### OTHER SECRETS
AWS_SECRET_ACCESS_KEY = "h50fH..."

我喜欢这个解决方案的原因是:

所有东西都在您的版本控制系统中，除了机密信息 大多数配置都在一个地方:common.py。 特定于产品的东西放在prod。py中，特定于开发的东西放在dev。py中。这很简单。 你可以在prod.py或dev.py中覆盖common.py中的内容，也可以覆盖__init__.py中的任何内容。 这是简单的python。没有重新导入黑客。

我使用settings_local.py和settings_production.py。在尝试了几个选项后，我发现当简单地拥有两个设置文件时，很容易在复杂的解决方案上浪费时间。

当你在Django项目中使用mod_python/mod_wsgi时，你需要将它指向你的设置文件。如果你把它指向本地服务器上的app/settings_local.py和生产服务器上的app/settings_production.py，那么事情就变得简单了。只需编辑适当的设置文件并重新启动服务器(Django开发服务器将自动重新启动)。