Django Local Settings
I'm trying to use local_setting in Django 1.2, but it's not working for me. At the moment I'm just adding local_settings.py to my project.
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. N开发者_如何学Goot used with sqlite3.
'PORT': '', # Set to empty string for default. Not used with sqlite3.
}
}
The problem is that local_settings.py doesn't override settings.py. What is wrong?
You can't just add local_settings.py, you have to explicity import it.
At the very end of your settings.py, add this:
try:
from local_settings import *
except ImportError:
pass
The try/except block is there so that Python just ignores the case when you haven't actually defined a local_settings file.
This is the best practice I think:
local_settings
imports fromsettings
local_settings
overrides settings specific to the local environment, especiallyDATABASES
,SECRET_KEY
,ALLOWED_HOSTS
andDEBUG
variables- pass to django management commands the flag
--settings=local_settings
You could implement local_settings
like this:
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.
}
}
A few additional key points:
settings.py
is in version control, written in a way such that it's ready to use by contributorslocal_settings.py
(or more commonlyprod_settings.py
) is NOT in version control, and used in production by specifying--settings=prod_settings
or similar.
Touching the stock settings file as little as possible also makes it easier to upgrade your django version. When you upgrade Django to the next version, look at the diff in the stock settings.py
and yours, and take actions as necessary depending on what changed. Changes in the default values can be important, and the less you touched the original settings.py
file, the easier it will be to discern upstream changes.
Since the topic resurfaces routinely let me summarise why you might want to consider this approach:
a dumb settings file is very fast and easy to change; especially in a production environment. No python required: any idiot can jump in and change the database password in a file which just lists names and values; especially compared to a complex python settings file full of mysterious dangerous BIGCAPS names.
the application
settings
should be completely separated from the applicationcode
. You can put a config.ini outside the repository root and never again worry about a repo pull clobbering your settings, or your personal settings polluting the repo, or that clever code in your settings.py not making it into the repo to everyone else's advantage.
This won't apply to small projects, but on bigger projects I've concluded that the local_settings strategy just doesn't cut it; over time enough application programming creeps in that it gets hard to handle; primarily as settings become derivative and/or codependent. There can be good justifications for settings to react according to the local settings which forces the import of a local_settings
file to creep up toward the middle of settings.py
. I find things start to get messy as that happens.
My current solution is to use a config
file, I dub it "local.ini". It holds only those values which do actually change between deployed instances. There is no code: they are just values and booleans:
[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
With this in place I can treat the settings.py
like any other piece of application code: tweak it, check it in, and deploy it without having to worry about testing against whatever code might be lurking in a local_settings python code. My settings.py
is free of race conditions that come up when later settings depend on local settings, and I can switch features on and off writing easy-to-follow linear code. No more hurriedly tweaking the local_settings file when I've forgotten to add some new value, and no more daves_local_settings.py
and bobs_local_settings.py
files creeping into the repository.
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'
If you encounter a BOFH, like I had on one occasion, he got particularly excited about the ability to stick the local.ini
into the /etc
directory as /etc/ourapp.ini
and so keep the application directory itself a pure repository export. Sure you could do that with a local_settings.py but the last thing he wanted to do was mess with python code. A simple config file he could handle.
I kept a copy of __local_settings.py
:
local_settings.py
is being ignored in the version control, but not__local_settings.py
- update
README.md
to inform the team on how to setup:cp {__,}local_settings.py
(which make a copy for their local_settings)
In the past
I used to import those settings.
# settings.py
DATABASE = {...}
try:
from .local_settings import *
except ImportError:
pass
now
I just import the settings itself from the local_settings.py
.
And with the following command: python manage.py runserver --settings=<proj>.local_settings
.
# local_settings.py & __local_settings.py
from .settings import *
DATABASE = {...}
And since, I usually don't interact with manage.py
directly, because some parameters are explicitly necessary for me, (e.g. address:port
). Therefore, I put all of those command into my Makefile
.
For example, here's my Makefile:
run:
python manage.py runserver 0.0.0.0:8000 --settings=<proj>.local_settings
sh:
python manage.py shell_plus --settings=<proj>.local_settings
dep:
npm install
pip install -r requirements.txt
Thus:
make dep
make sh
make run
Conclusion
Provided that you are not using Makefile
as your workflow, then you may use the earlier method, but if you are using makefile, then i believe it is better to be more explicit in your Makefile.
Before running the server do
export DJANGO_SETTINGS_MODULE=your_app_name.local_settings
where your_app_name should be replaced by your App's name.
And don't forget to do
from settings import *
in your local_settings.py file
Yet another approach is to use python-dotenv
and environment variables to customize settings for different environments.
Create the .env
file along-side your settings.py
:
# .env
SECRET_KEY=your-secret-key
DATABASE_PASSWORD=your-database-password
Add the following code to your settings.py
:
# settings.py
from dotenv import load_dotenv
load_dotenv()
# OR, explicitly providing path to '.env'
from pathlib import Path # python 3.4+
env_path = Path('.') / '.env'
load_dotenv(dotenv_path=env_path)
At this point, parsed keys/values from the .env
file are present as environment variables and they can be conveniently accessed via os.getenv()
:
# settings.py
import os
SECRET_KEY = os.getenv('SECRET_KEY')
DATABASE_PASSWORD = os.getenv('DATABASE_PASSWORD')
I found the similar solution. This is my configuration for this case:
settings.py:
DEBUG = False
try:
from local_settings import *
except ImportError:
pass
if DEBUG is False:
ALLOWED_HOSTS = ['sth.com']
DATABASES = {
....
}
local_settings.py:
from settings import *
ALLOWED_HOSTS = ['*']
DEBUG = True
DATABASES = {
...
}
Add this to the end of the file settings.py
try:
from .local_settings import *
except ImportError:
pass
And create file local_settings.py with your new settings for example
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.
}
}
精彩评论