Lazy-load CLI commands so augur --help works without DB config

[mezo78902]

Fixes #3654.

augur --help previously triggered eager imports of CLI command modules via click.MultiCommand.get_command(), which could initialize DB/config and exit before rendering help.

This change returns a lightweight lazy proxy command from get_command(), importing the actual command module only when invoked. short_help is parsed from command source as a best-effort to keep the top-level help informative without importing modules.

Scope is intentionally limited to a single file: augur/application/cli/_multicommand.py. Runtime behavior for actual command execution remains unchanged.

[mezo78902]

@MoralCode I opened a new minimal PR (#3661) that only changes _multicommand.py to lazy-load commands so augur --help works without DB config.

[MoralCode]

@MoralCode I opened a new minimal PR (#3661) that only changes _multicommand.py to lazy-load commands so augur --help works without DB config.

yep, thats this PR, thanks!

[MoralCode]

Can you provide some more detail on why this change was needed? this feels like a very structural change to the object that seems to be underlying almost every CLI command.

Was it the importing of this module that is dependent on the database?

[mezo78902]

Can you provide some more detail on why this change was needed? this feels like a very structural change to the object that seems to be underlying almost every CLI command.

Was it the importing of this module that is dependent on the database?

Great question — _multicommand.py itself is not database-dependent.

The issue is that Click builds the help output by calling get_command() for every command.
Before this change, get_command() eagerly imported each command module just to retrieve the command object and short_help.

Some of those command modules have import-time side effects or transitive imports that touch database or config logic, so augur --help could fail before any output was rendered in a fresh environment.

This change only defers importing the command module until the command is actually invoked.
Runtime behavior for augur <command> is unchanged — failures still occur at execution time if configuration is missing.

The change is isolated to CLI wiring and avoids touching DB, Redis, or runtime logic.

[MoralCode]

Some of those command modules have import-time side effects or transitive imports that touch database or config logic, so augur --help could fail before any output was rendered in a fresh environment.

Do you have a sense of how much of the CLI is impacted by this? if its only a couple files maybe its worth adjusting how the imports are structured so that click can do its job as intended.

[mezo78902]

Some of those command modules have import-time side effects or transitive imports that touch database or config logic, so augur --help could fail before any output was rendered in a fresh environment.

Do you have a sense of how much of the CLI is impacted by this? if its only a couple files maybe its worth adjusting how the imports are structured so that click can do its job as intended.

I actually just tested that exact approach by refactoring backend.py to move all top-level imports (tasks, celery, KeyClient) into local function scope. augur --help still failed with the same DB error.

That suggests the issue is transitive and affects more than a couple of files—importing one CLI module often pulls in others that eagerly touch DB/config at import time.

Refactoring imports file-by-file would likely turn into whack-a-mole. The lazy proxy approach here provides a safer, structural boundary that ensures --help works without impacting runtime behavior.

[mezo78902]

Hi @MoralCode
I tried a simpler approach that might better fit your concern about structural changes.
During top-level --help, get_command() returns a small placeholder command so help can render without importing modules.
Execution behavior stays exactly the same otherwise.

Happy to update the PR this way if that sounds reasonable.