Django Extension¶
Dynaconf a drop in replacement to .
Following this pattern recommended pattern this extension makes your Django’s in to a instance.
Initialize the extension¶
In your django project’s include:
# *Django `check` requires this before loading installed apps, this can be overwriten by dynaconf later
SECRET_KEY = True
# Load dynaconf
INSTALLED_APPS = [
'dynaconf.contrib.django_dynaconf',
...
]
NOTE: The extension must be included as the first INSTALLED_APP of the list
Use environment variables¶
Then django.conf.settings will work as a instance and will be the global prefix to export environment variables.
Example:
export DJANGO_DEBUG=true # django.conf.settings.DEBUG
export DJANGO_INTVALUE=1 # django.conf.settings['INTVALUE]
export DJANGO_HELLO="Hello" # django.conf.settings.get('HELLO)
Settings files¶
You can also have settings files for your Django app, in the root directory (the same where is located) put your and files and then define your environments , and .
To switch the working environment the variable can be used, so to work in development mode or to switch to production.
IMPORTANT: To use CLI the must be defined.
IF you don’t want to manually create your config files take a look at the CLI
NOTE: It is recommended that all the django’s internal config vars should be kept in the of your project, then application specific values you can place in dynaconf’s in the root (same folder as manage.py). You can override settings.py values in the dynaconf settings file as well.
Customizations¶
It is possible to customize how your django project will load settings, example: You want your users to customize a settings file defined in and you want environment variables to be loaded from
your django
SECRET_KEY = True
"""Django `check` requires the SECRET_KEY to exist before initialing
INSTALLED_APPS this value is set to True but will be overwritten after by the
value exported as PROJECTNAME_SECRET_KEY or defined in the file PROJECTNAME_SETTINGS"""
GLOBAL_ENV_FOR_DYNACONF = "PROJECTNAME"
"""This defines which environment variable global prefix dynaconf will load
That means that `export PROJECTNAME_FOO=1` will be loaded to `django.conf.settings.FOO
On command line it is possible to check it with `dynaconf list -k foo`"""
ENVVAR_FOR_DYNACONF = "PROJECTNAME_SETTINGS"
"""This defines which path dynaconf will look to load config files
example: export PROJECTNAME_SETTINGS=/path/to/settings.toml and the format can be
.ini, .json, .yaml or .toml
e.g::
export PROJECTNAME_SETTINGS=settings.toml
[default]
FOO = 1
[development]
FOO = 2
[production]
FOO = 3
OR::
export PROJECTNAME_SETTINGS=settings.yaml
default:
foo: 1
development:
foo: 2
production:
foo: 3
It is also possible to pass a list of files::
export PROJECTNAME_SETTINGS=settings.toml,other_settings.yaml,another.json
The variables will be cascaded in the defined order (last wins the precedence)
The environment variables wins precedence over all!
"""
# load dynaconf
INSTALLED_APPS = [
'dynaconf.contrib.django_dynaconf',
...
]
Then the working environment can now be switched using