我在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设置的博文。看看吧!

我在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是一个活动代码文件。假设您没有在生产中设置DEBUG(这是一个最佳实践)，您可以执行如下操作:

if DEBUG:
    STATIC_PATH = /path/to/dev/files
else:
    STATIC_PATH = /path/to/production/files

非常基本，但是理论上，您可以根据DEBUG的值或您想使用的任何其他变量或代码检查来提高任何复杂级别。

我在manage.py中区分它，并创建了两个单独的设置文件:local_settings.py和prod_settings.py。

在manage.py中检查服务器是本地服务器还是生产服务器。如果它是本地服务器，它将加载local_settings.py，如果它是生产服务器，它将加载prod_settings.py。基本上是这样的:

#!/usr/bin/env python
import sys
import socket
from django.core.management import execute_manager 

ipaddress = socket.gethostbyname( socket.gethostname() )
if ipaddress == '127.0.0.1':
    try:
        import local_settings # Assumed to be in the same directory.
        settings = local_settings
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'local_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file local_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)
else:
    try:
        import prod_settings # Assumed to be in the same directory.
        settings = prod_settings    
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'prod_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file prod_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)

if __name__ == "__main__":
    execute_manager(settings)

我发现将设置文件分开到两个单独的文件中更容易，而不是在设置文件中做大量的if。

Django 1.5的最佳实践建议对你的设置文件使用版本控制，并将文件存储在一个单独的目录中:

project/
    app1/
    app2/
    project/
        __init__.py
        settings/
            __init__.py
            base.py
            local.py
            production.py
    manage.py

base.py文件包含常见设置(如MEDIA_ROOT或ADMIN)，而local.py和production.py有特定于站点的设置:

在基本文件设置/base.py:

INSTALLED_APPS = (
    # common apps...
)

在本地开发设置文件settings/local.py中:

from project.settings.base import *

DEBUG = True
INSTALLED_APPS += (
    'debug_toolbar', # and other apps for local development
)

在文件生产设置文件设置/production.py:

from project.settings.base import *

DEBUG = False
INSTALLED_APPS += (
    # other apps for production site
)

然后当你运行django时，你添加——settings选项:

# Running django for local development
$ ./manage.py runserver 0:8000 --settings=project.settings.local

# Running django shell on the production site
$ ./manage.py shell --settings=project.settings.production

这本书的作者还在Github上发布了一个示例项目布局模板。

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

我保留了一个名为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文件，这意味着我不能盲目地复制所有文件，但这是我可以接受的。