from project.settings.base import *
DEBUG = True
INSTALLED_APPS += (
'debug_toolbar', # and other apps for local development
)
在文件生产设置文件settings/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
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..."
Two Scoops of Django: Best Practices for Django 1.5建议对设置文件使用版本控制,并将文件存储在单独的目录中:
base.py
文件包含公共设置(例如媒体根或管理员),而local.py
和production.py
具有特定于站点的设置:在基本文件
settings/base.py
中:在本地开发设置文件
settings/local.py
中:在文件生产设置文件
settings/production.py
中:然后在运行django时,添加
--settings
选项:这本书的作者还在Github上贴了a sample project layout template
使用以下布局代替
settings.py
:common.py
是大多数配置所在的位置prod.py
从common导入所有内容,并覆盖需要覆盖的内容:类似地,
dev.py
从common.py
导入所有内容并覆盖它需要覆盖的任何内容最后,
__init__.py
是决定加载哪些设置的地方,也是存储机密的地方(因此不应对该文件进行版本控制):我喜欢这个解决方案的地方是:
common.py
李>prod.py
,特定于开发的东西放在dev.py
。很简单李>prod.py
或dev.py
中common.py
的内容,并且可以覆盖__init__.py
中的任何内容李>在
settings.py
中:您可以覆盖
local_settings.py
中需要的内容;那么它应该不受您的版本控制。但既然你提到了复制,我猜你没有使用;)相关问题 更多 >
编程相关推荐