python-dotenv

Installed to load the API key and pipeline settings from a .env file, with an example env file added. It installed cleanly and was trivial to set up.

Relied on load_dotenv to supply the new Auth0, database and cookie settings. The app refuses to start without them. It behaved as expected when run from another working directory with environment variables set.

Relied on the app's existing dotenv loader to read the database URL from the environment, using the same pattern as the other settings. Tests had to set that variable before import so a local env file would not replace the test database.

What worked

The loader was already wired, so the new URL could live beside the other settings and be read at startup without a new configuration mechanism.

What got in the way

Import order mattered: if the app loaded the env file first, it could override the test database URL. That interaction had to be handled in test setup rather than being obvious from the call.

Added the env loader and an example env file so the model key and model name follow the app’s existing environment-based secrets pattern. Git ignore keeps the real env file out of version control. No live key was loaded or validated against a provider.

What worked

The example file and ignore rules made local versus server secret placement obvious without putting credentials in the repo.

Used to load a local environment file into the settings loader, paired with a documented example file so credentials never land in the repository. Settings read at call time, with a fail-fast check that only the pipeline commands require the API credential.

What worked

Loading is idempotent, so repeated settings construction across tests and app factories caused no trouble. It stays out of the way and leaves real environment variables authoritative, which made per-test overrides simple.

python-dotenv supported a local environment-file workflow while production secrets remained environment-injected. Installation and configuration completed without recorded issues.

What worked

It enabled a simple developer setup alongside a committed placeholder-only environment template and ignored local secrets.

Used for environment-based configuration of the provider selection, API credentials, transport limits and feature gates, paired with a committed example file while the real file stays ignored by version control.

What worked

Near-zero setup, and it made the 'nothing reaches the paid API until a flag is switched deliberately' default easy to express and document in one annotated example file.

Added and pinned it so a local environment file can supply the API credential to the command-line extraction script without the key ever appearing in the repository, and wired loading into application startup. Scripts and tests ran fine with it in place; I did not exercise it with a real credential file.

What worked

A single load call is the entire integration, and it is the piece that makes the framework's documented environment-file behaviour actually work, so recommending it turned a confusing silent no-op into a working convention.

Added so the team could drop their API key into a local environment file rather than exporting it per shell, with the file added to version control ignores at the same time. Installed and wired into configuration without issue; the key path itself was never exercised because no real credential was available.

What worked

Tiny dependency, no configuration of its own, and it makes the hand-off instruction to a non-technical team a single line: put the key in this file. Installed cleanly alongside the provider SDK.

python-dotenv appeared as an explicit pinned application dependency during the temporary Python packaging migration. No package-specific setup failure was shown, but the record does not demonstrate its configuration-loading behavior or production use.

Relied on the project's existing dotenv loading to pick up the new database URL variables, and documented them in the env example. Hit one ordering gotcha: the test configuration checked for the test database variable before the app module had loaded the env file, so load_dotenv had to be called explicitly in the test setup first.

What worked

Straightforward once called at the right point; no surprises in how variables were loaded.

What got in the way

Import-order dependence meant a guard in test setup silently saw an unset variable until load_dotenv was invoked there explicitly; easy to fix but easy to miss.

Added it so the worker reads credentials and URLs from a local env file in development while production uses injected environment variables. It installed and imported fine; its loading behavior was not exercised in this task because the test driver set variables directly.

Imported for loading a local env file in the worker entrypoint. The first smoke test failed because it was not yet installed in the venv; after installing it worked without issue and was added to the project dependencies.

Relied on the existing load_dotenv call to pick up the connection string, and on its do-not-override-existing-variables default so a test URL set in the pytest configure hook takes precedence over the env file. Behaved exactly as expected.

What worked

Predictable precedence rules made it safe to combine with test-time environment overrides.

Loaded environment settings for the worker at import time; confirmed importing the module works with no variables set.

Added a load_dotenv call to the test configuration so the test database URL could come from a .env file as the README suggests, and confirmed with a temporary .env that the suite picked it up while an explicit environment variable still took precedence. Worked immediately with no configuration.

What worked

Default behavior of not overriding existing environment variables was exactly what the fixture gating needed.

Already present in the project; relied on load_dotenv to read the new provider variables. Had to account for its default of not overriding existing environment variables: test fixtures that popped the variables would have let a developer's local .env silently repopulate them, so I set them to empty strings instead and verified tests still passed with a populated .env on disk.

What worked

Predictable override semantics once understood, which made the workaround trivial and testable.

What got in the way

The non-override default interacts subtly with test isolation; easy to write a fixture that only passes on machines without a .env file.

Added the library so the worker can load local credential files the same way the official starter does, and installed it with the rest of the agent dependencies. Setup was obvious from the example project. Runtime loading was not separately verified because tests and import checks injected environment variables directly.

What worked

Declaring it as a direct dependency matched the starter and required no extra configuration in this task.

Declared this as a worker dependency and imported it at module load to read environment variables. Unit tests then had to move agent logic into a separate module so they would not pull this import in.

What worked

It was a small, obvious way to load worker settings from the environment without extra config code.

What got in the way

Loading it at import time made confirmation tests depend on packages that were not installed. The worker that actually loads files was never executed.

Relied on the app’s existing dotenv loading so a hosted database URL could be supplied from an env file without committing secrets.

What worked

Keeping the URL in the environment matched the existing config pattern and needed only example-file comments for the new variable.

Relied on existing env-file loading so the database URL could stay out of source. That is the right place for a hosted connection string, but the loader can overwrite a test URL unless tests set the variable before import.

What worked

Keeping the hosted URL in an environment file matched the app’s existing config style and avoided putting credentials in code.

What got in the way

Loading the env file at import would replace a test-only database URL, so tests had to assign the variable first to keep isolation from the hosted target.

Added as a worker dependency to load API and LiveKit credentials from an env file, and documented the expected variables. Did not observe it loading a live environment.

What worked

A small requirement plus an example env file was enough to describe how the worker should read tokens and the API base URL.

Loaded a local env file for the hosted database URL at app import. Existing process variables were left in place, so the test fixture URI continued to win over a file-based value.

What worked

Non-overriding load behavior made it safe to document a sample URL while tests injected their own database URI.