Configuration

All applications should read configuration from environment variables, like in the Twelve-Factor App methodology.

In development, the default values should be appropriate as-is. The default values can be overridden in other environments with, for example, a uWSGI INI file or a Docker Compose .env file in production or a GitHub Actions workflow in testing.

For command-line interfaces, configure the environment variables in a .env file. Use python-dotenv (not django-environ) to load the file: for example, Kingfisher Summarize.

Otherwise, read configuration from INI files using configparser. Do not use: JSON (no comments), YAML (data typing, too many features, not in standard library), TOML (data typing, too many features, not in standard library until Python 3.11), or XML (verbose, not in standard library).

See also

Django settings guide

Word choice

Use the following names for environment variables:

  • LOG_LEVEL

  • Local services

    • DATABASE_URL (see PostgreSQL)

    • RABBIT_URL (see RabbitMQ)

    • RABBIT_EXCHANGE_NAME (see RabbitMQ)

    • *_URL (not *_HOST, unless it is only the host part, like localhost)

  • Third-party services

    • FATHOM_ANALYTICS_DOMAIN

    • FATHOM_ANALYTICS_ID

    • SENTRY_DSN (not DNS!)

    • SENTRY_SAMPLE_RATE

If a setting refers to a setting in another project, prefix it by the project’s full name. For example:

  • KINGFISHER_PROCESS_DATABASE_URL, not PROCESS_DATABASE_URL

Deployment

Environment variables are configured in Pillar files in the deploy repository (see documentation).