我正尝试在Django1.2中使用local_setting,但它不适合我。目前,我只是将local_settings.py添加到我的项目中。
settings.py
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'banco1', # Or path to database file if using sqlite3.
'USER': 'root', # Not used with sqlite3.
'PASSWORD': '123', # Not used with sqlite3.
'HOST': 'localhost', # Set to empty string for localhost. Not used with sqlite3.
'PORT': '', # Set to empty string for default. Not used with sqlite3.
}
}
local_settings.py
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'banco2', # Or path to database file if using sqlite3.
'USER': 'root', # Not used with sqlite3.
'PASSWORD': '123', # Not used with sqlite3.
'HOST': 'localhost', # Set to empty string for localhost. Not used with sqlite3.
'PORT': '', # Set to empty string for default. Not used with sqlite3.
}
}
问题是local_settings.py不会覆盖settings.py.怎么啦?
发布于 2011-02-06 06:00:32
你不能仅仅添加local_settings.py,你必须显式地导入它。
在您的settings.py末尾,添加以下内容:
try:
from local_settings import *
except ImportError:
pass
try/except块在那里,这样当您还没有实际定义local_settings文件时,Python就会忽略这种情况。
发布于 2013-01-27 14:58:49
这是我认为的最佳实践:
从settings
local_settings
导入的local_settings
会覆盖特定于本地环境的设置,尤其是对django variables--settings=local_settings
标志命令的DATABASES
、SECRET_KEY
、ALLOWED_HOSTS
和DEBUG
命令
您可以像这样实现local_settings
:
from settings import *
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'banco2', # Or path to database file if using sqlite3.
'USER': 'root', # Not used with sqlite3.
'PASSWORD': '123', # Not used with sqlite3.
'HOST': 'localhost', # Set to empty string for localhost. Not used with sqlite3.
'PORT': '', # Set to empty string for default. Not used with sqlite3.
}
}
以下是其他几个关键点:
settings.py
在版本控制中,其编写方式使其可供contributorslocal_settings.py
使用(或者更常见的prod_settings.py
)不在版本控制中,并通过指定--settings=prod_settings
或类似的方式在生产中使用。尽可能少地接触股票设置文件也可以更容易地升级您的django版本。当您将Django升级到下一个版本时,请查看现有settings.py
和您的版本之间的差异,并根据更改的内容采取必要的措施。默认值的更改可能很重要,您接触原始settings.py
文件的次数越少,就越容易识别上游的更改。
发布于 2013-09-11 09:05:57
由于这个话题经常重新浮出水面,让我总结一下为什么你可能想要考虑这种方法:
settings
应该与应用程序code
完全分开。您可以在存储库根目录之外放置一个config.ini,再也不用担心repo请求会破坏您的设置,或者您的个人设置会污染repo,或者settings.py中的聪明代码不会对其他所有人都有利。这不适用于小项目,但对于较大的项目,我得出的结论是local_settings策略无法解决问题;随着时间的推移,大量的应用程序编程逐渐变得难以处理;主要是因为设置变得派生和/或相互依赖。可以有很好的理由让设置根据本地设置做出反应,这会强制local_settings
文件的导入向settings.py
中间缓慢移动。我发现事情开始变得一团糟。
我目前的解决方案是使用一个config
文件,我将其命名为"local.ini“。它只保存那些在已部署的实例之间实际发生更改的值。没有代码:它们只是值和布尔值:
[global]
domain = 127.0.0.1:8000
database_host = 127.0.0.1
database_name = test_database
debug = Yes
google_analytics_id = UA-DEV-1
payments = testing
use_cdn = No
有了这些,我就可以像对待任何其他应用程序代码一样对待settings.py
:调整它、签入和部署它,而不必担心对local_settings python代码中可能隐藏的任何代码进行测试。我的settings.py
没有竞争条件,当以后的设置依赖于本地设置时,我可以切换功能,编写易于遵循的线性代码。当我忘记添加一些新值时,不再匆忙调整local_settings文件,也不再有daves_local_settings.py
和bobs_local_settings.py
文件悄悄进入存储库。
from ConfigParser import RawConfigParser
parser = RawConfigParser()
APPLICATION_ROOT = path.abspath(path.dirname(__file__))
parser.readfp(open(path.join(APPLICATION_ROOT, 'local.ini')))
# simple variables
DATABASE_HOST = parser.get('global', 'database_host')
DATABASE_NAME = parser.get('global', 'database_name')
# interdependencies
from version import get_cdn_version
CDN = 'd99phdomw5k72k.cloudfront.net'
if parser.getboolean('global', 'use_cdn'):
STATIC_URL = '/{}/static/{}/'.format(CDN, get_cdn_version())
else:
STATIC_URL = '/static/'
# switches
payments = parser.get('global', 'payments')
if payments == 'testing':
PAYMENT_GATEWAY_ENDPOINT = 'https://api.sandbox.gateway.com'
else:
PAYMENT_GATEWAY_ENDPOINT = 'https://api.live.gateway.com'
如果您遇到BOFH,就像我有一次遇到的那样,他特别兴奋的是能够将local.ini
作为/etc/ourapp.ini
放入/etc
目录中,从而保持应用程序目录本身是一个纯存储库导出。当然,使用local_settings.py也可以做到这一点,但他最不想做的事情就是弄乱python代码。一个他可以处理的简单配置文件。
https://stackoverflow.com/questions/4909958
复制相似问题