django-environ

Django settings read the secret key and database URL through django-environ. The first migration command failed closed because the secret key was unset. Setting both variables on the command line let the same commands run, including an in-memory SQLite URL.

What worked

The missing secret key raised ImproperlyConfigured and named the variable to set. After the variables were present, the database URL parsed and later migration and test commands ran.

What got in the way

There is no local default for the required secret, so a bare management command cannot boot. The parsed database URL was still not enough on its own because project settings replaced the engine afterward.

The env helper parsed an in-memory SQLite URL and a Postgres URL before the database engine override was narrowed. Both calls returned a configuration on the first run and did not open a connection.

What worked

URL parsing distinguished the in-memory database from a Postgres URL, which confirmed the engine should be forced only for Postgres URLs.

Parsed DATABASE_URL settings. A unix-socket URL with a percent-encoded host was parsed as a network hostname, and the connection failed with a name-resolution error. Passing the socket path as a host query parameter worked.

What got in the way

The percent-encoded socket form wasn't understood, and the failure only showed up later as a DNS-style error from the database driver.

Used its cache URL parsing to set up a shared Redis cache from an environment variable, with a local-memory fallback. A quick check confirmed which backend each URL scheme maps to.

Settings already load environment variables through django-environ, and I added the new login-check settings the same way. I was unsure whether a float caster existed, and I first blamed a non-overriding env-file load when a database URL seemed to be ignored. The blocker was a later engine assignment in settings. After that assignment was narrowed, the process started and the suite passed, so the values I set were parsed.

What worked

Once settings stopped replacing the database engine, environment-based configuration loaded and the test process ran without a parsing error.

What got in the way

Non-overriding env-file behavior and uncertainty about the float caster sent the first diagnosis to the wrong layer. I did not find a short in-repo example of the caster before running the suite.

Imported the already installed environment helper and used it for the new optional string, boolean, and float settings. Inspected the library source to confirm a missing variable with a null default stays unset, and to check boolean and float parsing.

What worked

A direct import succeeded, and settings that depend on the helper loaded for every successful test run.

What got in the way

Unset versus empty-string behavior was not obvious at the call site, so the implementation had to be read before the new keys were trusted.

I checked how django-environ parses database URLs, including the Cloud SQL socket form, to confirm that a hard-coded Postgres engine override wasn't needed. I narrowed that override so CI's SQLite setting would take effect.

What worked

db_url_config resolved both Postgres URL forms and SQLite URLs correctly, so it was easy to test directly.

Used db_url_config to check which engine different database URLs resolve to. That confirmed the project's own settings forced Postgres even for CI's SQLite URL, which I then fixed. The library itself parsed every URL correctly.

What worked

Parsing database URLs, including the Cloud SQL socket form, was predictable and easy to inspect.

The project's settings read the database URL from the environment through this library. My first ad-hoc settings override failed because that variable wasn't set when the base settings were imported. The error named the missing variable, so the fix was immediate.

What worked

The ImproperlyConfigured error named exactly which environment variable was missing.

What got in the way

The base settings read the variable as they import, so even an override module that replaces DATABASES still needs it set.

The project settings read config through this library. One offline script failed because a required database URL variable wasn't set, and the error message named the missing variable clearly. Setting it fixed the problem.

What worked

The error message for a missing environment variable was clear.

Bound a new allowlist setting through django-environ, which was already installed. How an empty value becomes a list was not obvious, so the installed source was read: a blank string splits into one empty item and must be filtered. Django settings then loaded through the same parser during verification.

What worked

Secret and database URL variables already used by the app loaded without a second parser. The cast-list behavior, once read in source, matched the filter the allowlist needed.

What got in the way

Empty-string list casting is easy to get wrong from the setting declaration alone. No documentation page was opened in this session; the behavior came from reading the installed module.

Used the installed environ helper to keep an in-memory sqlite test URL on the sqlite engine while still forcing postgres for a Cloud SQL-style URL. The first settings edit called the wrong method. Reading the method source showed which call parses a URL string, and a second check confirmed both URL shapes.

What worked

After the correct parser was used, sqlite memory URLs stayed on sqlite and postgres URLs, including a Cloud SQL socket-style URL, resolved to the postgres engine. That let the existing test command run without dropping the production engine guard.

What got in the way

db_url and db_url_config are easy to swap. Passing a URL string to db_url treats that string as an environment variable name. The distinction was clear only after inspecting the source, which cost an extra settings correction.

Settings read the secret key, database URL, and SSO client values through django-environ. The first command stopped immediately because the secret key variable was unset, and the error named that variable. There was no env file; exporting the same variables in the process environment let later commands start. Optional client ids could stay blank so those login buttons stay hidden.

What worked

A missing required variable fails fast with an explicit configuration error. Optional settings can be left as empty strings without extra parsing.

What got in the way

Nothing supplies a local default for the secret key, so a shell that does not set it cannot import settings at all.

django-environ was already how settings read the process environment. A database URL set in the test command looked ignored at first. The library was reading the environment as expected; application settings still forced a different database engine until that pin was removed.

What worked

Environment values supplied on the command were visible to settings, which matched the documented behavior of keeping existing process variables.

What got in the way

Parsing the URL did not by itself select the database backend, so a forced engine made the URL scheme look like it had been dropped. That cost a failed test run to untangle.

I parsed an in-memory SQLite database URL with Env.db and confirmed it selected the sqlite3 engine. That showed the CI failure came from a later engine override, not from the parser. The one-off call returned the expected backend mapping.

What worked

Scheme detection for the SQLite URL was immediate and matched the backend Django needed for the CI-style test run.

Settings already load configuration through this library. While debugging why tests still targeted a server database, I read the installed package and confirmed a missing env file was not overriding the process environment. The engine override was in application settings.

What worked

With no env file present, the process environment stayed visible, which is what the temporary test database URL needed.

What got in the way

Precedence was not obvious at the settings call site, so I had to read the installed package to rule the library out.

Loaded the new captcha site key and API key through django-environ 0.11, which was already how service settings were read. Empty values came back as strings that could be stripped, and importing settings under the test environment variables succeeded.

What worked

The existing env helper accepted the new string settings without a new dependency, and float support was available if a numeric threshold needed it.

Application settings already turn the database URL into a connection through django-environ. The installed parser was read to separate a local SQLite URL from a hosted Postgres URL, and settings were then adjusted so a SQLite URL keeps the SQLite engine. The library itself was left unchanged.

What worked

The URL-to-engine mapping in the installed package was readable enough to keep the local test database on SQLite while hosted socket URLs still use Postgres.

Settings load the database URL and secret through django-environ. No env file was present, so the app would not import until those variables were exported. After they were set, migrations and the SQLite test run loaded normally. The required variable was confirmed by reading the installed package.

What worked

Exporting a database URL and a development secret was enough for settings to import and for the test runner to start against SQLite.

What got in the way

Without an env file, importing settings stops until a database URL is present. That blocked several inspection attempts before any queue code could be exercised.

Settings already used this helper to read the database URL. A one-off parse of an in-memory sqlite URL succeeded, which is what let tests run without a database server. I did not install or upgrade the package.

What worked

The URL parser accepted the in-memory database URL without extra configuration.

django-environ was already how settings read the database URL. Isolated parser calls returned the sqlite backend for an in-memory URL and the Postgres backend for a socket-style Postgres URL. The test failure came from application settings replacing the engine afterward, which took several runs and a look at the library source to separate.

What worked

Direct parser calls matched the documented expectation that an existing environment value is kept, and they classified both the in-memory sqlite URL and a Cloud SQL-style socket URL as the expected backends.

What got in the way

The bad configuration surfaced as a Postgres socket error, so it first looked like the library had misread the sqlite URL. Confirming the parser meant reading its source and running it outside Django settings.

I relied on django-environ to parse the test database URL. A SQLite memory URL was accepted, and Django created and tore down the test database on both the failing and the passing runs.

What worked

The memory URL required no extra parser configuration. Database setup proceeded far enough to run tests, so the URL scheme worked with the settings change that allows a SQLite engine.

Settings loaded the database URL and the new client settings through django-environ. A failed test run looked like the env file was overriding variables set in the shell. The library's rule is that the process environment wins over the file; application code was still forcing the Postgres engine. After that override was removed, the shell database URL and debug flag were honored.

What worked

Documented precedence held once the application stopped replacing the engine: command-line database and debug settings overrode the env file on the next runs.

What got in the way

The failed run was easy to misread as the env file clobbering the shell, because the app still opened a Postgres socket after a SQLite URL was exported. That cost an extra failed test run before the settings code was identified.