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

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

yep, thats this PR, thanks!

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?

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 callingget_command() for every command.
Before this change,get_command() eagerly imported each command module just to retrieve the command object andshort_help.

Some of those command modules have import-time side effects or transitive imports that touch database or config logic, soaugur --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 foraugur <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.

Some of those command modules have import-time side effects or transitive imports that touch database or config logic, soaugur --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.

Some of those command modules have import-time side effects or transitive imports that touch database or config logic, soaugur --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.

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.

Id be curious to know whetherclick is doing any kind of intelligent generation of the help text based on things other than theshort_help arg that you seem to be targeting in this PR (i suspect it does)

Having a demo of what your code outputs for the help text would also be nice to have as a proof of concept

Im worried there may not be a good solution here besides fixing the underlying "database connection needed at import time" issue, which is a very major change

Thanks — you’re right about the proxy still importing. I haven’t pushed the placeholder approach yet; I just tested it locally. I’ll update this PR to the placeholder-only-for-top-level-help version (no imports during augur --help, no short_help parsing) and add the demo output.

no imports during augur --help, no short_help parsing

is this going to make the help text less useful?

no imports during augur --help, no short_help parsing

is this going to make the help text less useful?

A little, yes — it may be a little less informative because we’d lose the per-command short_help lines in the top-level listing.
But it still shows Usage, options, and the full command list, which is the main onboarding need.
If we want to restore summaries later without imports, we could add a small static registry, but I’d prefer keeping this PR minimal for now.

Just to clarify — I haven’t pushed the placeholder-based update yet. The current PR still reflects the lazy proxy implementation.

Before updating the PR, I’d really appreciate your perspective — do you feel that omitting short_help is an acceptable tradeoff for ensuring --help works reliably without DB configuration?

Before updating the PR, I’d really appreciate your perspective — do you feel that omitting short_help is an acceptable tradeoff for ensuring --help works reliably without DB configuration?

yeah lets do that. its not ideal but having a dynamic list of all the commands that exist is probably more helpful

The other option is to put a copy of the help output in the docs somewhereas a workaround and tackle the long term solution to this at once (but i worry we will forget to follow up on that.

In addition to moving ahead on this, id be curious how possible you think it might be to use AST-like methods to parse through the files to recover the short_help and re-attach them to their relevant help items. I suspect this should be a separate PR though

Hi@MoralCode,

I’ve updated the PR to use the simpler placeholder-only approach we discussed.

During top-level augur --help, get_command() now returns a minimal click.Command(name=...) so that help can render without importing any command modules. No imports occur during help generation.

The normal execution path for augur remains unchanged — modules are still imported at invocation time as before.

As agreed, this version intentionally omits per-command short_help lines in the top-level listing to avoid any import-time side effects.

Here is the output in a fresh environment with no DB configuration:

$ augur --help
Usage: augur [OPTIONS] COMMAND [ARGS]...

Augur is an application for open source community health analytics

Options:
--help Show this message and exit.

Commands:
api
backend
cache
collection
config
csv_utils
db
github
jumpstart
tasks
user

Please let me know if this aligns better with your expectations. I’d be happy to explore an AST-based approach for restoring short_help in a separate follow-up PR.

It may be worth including a message in this limited output To explain that the output is intentionally limited because there's no database access available and linking to the issue.

Thanks for the suggestion — I’ve added a brief note to the help output explaining that it is intentionally limited when no database configuration is available, and linked to#3654 for context.

Please let me know if this wording looks appropriate.