Command panels doesn't work with Click Lazy Loading

[gdlx]

Hi !
I'm using rich-click with an app with a root group including some subcommands.
To speed up the app init, I'm using click Lazy Loading example with success until rich-click 1.8:
https://click.palletsprojects.com/en/stable/complex/#defining-the-lazy-group

But starting with rich-click 1.9, the help page doesn't show commands anymore.

Before 1.9:

Since 1.9:

My root group code looks like this:

@click.group(
    cls=ClickAppGroup,
    lazy_subcommands={
        "build": "it4c.builder.cli.run",
        "products": "it4c.products.cli.run",
        "ci": "it4c.ci.cli.run",
        "export_api_versions": "it4c.apiversions.cli.run",
        "karma": "it4c.karma.cli.run",
        "test": "it4c.test.cli.run",
    },
)

(ClickAppGroup is just click example's LazyGroup renamed to be less ambiguous in my app)

Adding a command_panel instruction almost fixes the issue but I didn't find how to keep each command's name instead of the target function's:

@click.command_panel(
    "Test", commands=["build", "products", "ci", "export_api_versions", "karma", "test"]
)

Is there a fix or a workaround I could use to get the old behavior ? (knowing I really expected the panels feature to group subcommands options!)

Thanks !

[gdlx]

I just found a workaround: renaming my run functions with the click command names.
It would be nice not to have to add a command_panel for the default commands group though.

[dwreeves]

Hi @gdlx,

There are two sources of issues here, and I will chalk them both up to a regression on our end, and we can look into fixing it.

The first is the command names failing to load into the panel by default. This issue is easy to explain, and this is the reason why:

rich-click/src/rich_click/rich_panel.py

Lines 313 to 318 in f041971

	@classmethod
	def list_all_objects(cls, ctx: Context) -> List[Tuple[str, Command]]:
	if not isinstance(ctx.command, Group):
	return []
	return list(sorted(list(ctx.command.commands.items())))

There was a reason I did it this way but I sort of forget the full reasoning. In any case, it seems to be a potential source of issues, so we can move to the public interface so that it's easier to override.

The second issue-- everything being named run-- is a little harder to explain. I suspect that it may have something to do with the commands being named at the group level, not the command level. In normal circumstances we unit-test that names assigned at the group level are respected, see:

rich-click/tests/help/fixtures/panels_sorting.py

Lines 127 to 132 in f041971

	def cmd9(*args: Any, **kwargs: Any) -> None:
	"""
	Test that command and option both having the same name
	doesn't cause any issues. Also test that commands render by
	assigned name in dict, not by the cmd.name.
	"""

and

rich-click/tests/help/test_panels_sorting.py

Lines 271 to 294 in f041971

	def test_panel_option_and_command_same_name(cli_runner: CliRunner, cli: rich_click.RichCommand) -> None:
	result = cli_runner.invoke(cli, "cmd9 --help")
	assert result.exit_code == 0
	assert result.stdout == snapshot(
	"""\
	\n\
	Usage: cli cmd9 [OPTIONS] COMMAND [ARGS]... \n\
	\n\
	Test that command and option both having the same name doesn't cause any issues. Also test that \n\
	commands render by assigned name in dict, not by the cmd.name. \n\
	\n\
	╭─ Custom Opt Panel ───────────────────────────────────────────────────────────────────────────────╮
	│ --samename TEXT │
	│ --dummy TEXT │
	╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
	╭─ Options ────────────────────────────────────────────────────────────────────────────────────────╮
	│ --help Show this message and exit. │
	╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
	╭─ Commands ───────────────────────────────────────────────────────────────────────────────────────╮
	│ samename │
	╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
	"""
	)
	assert result.stderr == snapshot("")

but it seems that something in your custom class is breaking this.

Unfortunately I don't have time in the next few days to fix this, but by next weekend we can probably have a fix in?

[gdlx]

Thanks for the detailed answer.
I've found a second workaround by calling add_panel in the LazyGroup init:

    def __init__(
        self,
        *args,
        lazy_subcommands: dict[str, str] | None = None,
        **kwargs,
    ) -> None:
        super().__init__(*args, **kwargs)
        self.lazy_subcommands = lazy_subcommands or {}

        self.add_panel(
            rich_click.RichCommandPanel(
                "Commands", commands=list(self.lazy_subcommands.keys())
            )
        )

It's far from perfect but those both fixes allow me to get the same result as before 1.9 until a fix is released.

[dwreeves]

Ahhh, I forgot to address this in rich-click 1.9.2, as I was looking at the issues tab. This should be an issue, and I'll open one. That said, I don't think it is a high priority, as there is a way around it and in general, subclassed behavior is not always expected to be perfectly stable across minor versions.

[gdlx]

Yes, sorry, I should have opened an issue but I wasn't sure it was on rich-click side.

Do you want me to open one ?

[dwreeves]

Do you want me to open one ?

It's fine. It should be fixed now. Another large library had a similar issue and I figured this was too widespread an issue and needed to address more quickly. Thanks for reporting!

[gdlx]

I confirm lazy commands are now displayed automatically by default.
Regarding the other issue, I've just renamed the functions to match the command name as expected by click anyway.
Thanks a lot!