Configuring the Benefits app ¶
The Getting Started section and sample configuration values in the repository give enough detail to run the app locally, but further configuration is required before many of the integrations and features are active.
There are two primary components of the application configuration:
- Overall app settings in environment variables
- Content and more specific configurations in the data migration file
Many (but not all) of the environment variables are read into Django settings during application startup.
The model objects defined in the data migration file are also loaded into and seed Django’s database at application startup time.
See the Setting secrets section for how to set secret values for a deployment.
Django settings ¶
Settings file
Django docs
The Django entrypoint for production runs is defined in benefits/wsgi.py
.
This file names the module that tells Django which settings file to use:
import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "benefits.settings")
Elsewhere, e.g. in manage.py
, this same environment variable is set to ensure benefits.settings
are loaded for every app command and run.
Using configuration in app code ¶
Django docs
From within the application, the Django settings object and the Django models are the two interfaces for application code to read configuration data.
Rather than importing the app’s settings module, Django recommends importing the django.conf.settings
object, which provides
an abstraction and better handles default values:
from django.config import settings
# ...
if settings.DEBUG:
# do something when debug is enabled
else:
# do something else when debug is disabled
Through the Django model framework, benefits.core.models
instances are used to access the configuration data:
from benefits.core.models import TransitAgency
agency = TransitAgency.objects.get(short_name="ABC")
if agency.active:
# do something when this agency is active
else:
# do something when this agency is inactive