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. Not 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?
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--settings=local_settings
You could implement
local_settings
like this: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 originalsettings.py
file, the easier it will be to discern upstream changes.Add this to the end of the file settings.py
And create file local_settings.py with your new settings for example
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 doin your local_settings.py file
You can't just add local_settings.py, you have to explicity import it.
At the very end of your settings.py, add this:
The try/except block is there so that Python just ignores the case when you haven't actually defined a local_settings file.
I kept a copy of
__local_settings.py
:local_settings.py
is being ignored in the version control, but not__local_settings.py
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.
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
.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 myMakefile
.For example, here's my Makefile:
Thus:
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.Yet another approach is to use
python-dotenv
and environment variables to customize settings for different environments.Create the
.env
file along-side yoursettings.py
:Add the following code to your
settings.py
:At this point, parsed keys/values from the
.env
file are present as environment variables and they can be conveniently accessed viaos.getenv()
: