✨ Enhance command alias handling and display

[pipinstalled]

• Added support for positional and additional aliases in the command decorator.
• Updated format_commands to display command names along with their visible aliases.
• Improved command listing to maintain original order and avoid duplicates.
• Enhanced command info structure to include aliases and hidden aliases.

This improves the usability and clarity of command help output.

[github-actions]

📝 Docs preview

Last commit b91a994 at: https://e450f7c8.typertiangolo.pages.dev

Modified Pages

• https://e450f7c8.typertiangolo.pages.dev/tutorial/commands/name/ - (before)

[svlandeg]

@pipinstalled: you can go ahead and set add # pragma: no cover to the pass statements in the tests, otherwise the coverage check will keep failing.

[pipinstalled]

@pipinstalled: you can go ahead and set add # pragma: no cover to the pass statements in the tests, otherwise the coverage check will keep failing.

@svlandeg I added # pragma but still coverage failed

[svlandeg]

@pipinstalled: you can go ahead and set add # pragma: no cover to the pass statements in the tests, otherwise the coverage check will keep failing.

@svlandeg I added # pragma but still coverage failed

You'll have to look into the specifics of the coverage report. What this typically means is that there's a code path that is untested, so you'd have to implement more tests to cover it.

[pipinstalled]

@svlandeg Thanks for your help, fixed with adding new tests.

[pipinstalled]

@svlandeg Have you any idea when this PR will merge? :D

[pipinstalled]

@tiangolo Do you have any idea when this PR will merge? :)

[basnijholt]

This is great! Right now I am hacking around it (basnijholt/compose-farm#148).

[onyx-and-iris]

This will be great, I went the route of creating a custom alias class but I recently realised it broke shell completion :/ Thanks for all the efforts you've gone to with this PR.

[svlandeg]

Thanks for the PR, @pipinstalled!

I can see how it can be useful to define an alias for a given command.

In this specific PR, there are two ways implemented to accomplish that: either by positional arguments, or using an aliases= parameter. I'm not usually keen on implementing different ways of accomplishing the same thing: it creates confusion for users and unnecessary code maintenance.

Further, there is already a way (on master) to register different names for the same command:

@app.command("list")
@app.command("ls")
@app.command("listthem", hidden=True)
def list_items():
    print("Listing items")

I know that that would show up slightly differently in the help, they would show up as separate commands. At the same time I do also worry that this PR adds a new format_commands function and edits the Rich formatting in _print_commands_panel - it feels like these are potential cases for regressions or future issues.

TLDR: I'm not convinced that this a feature we'll want to support, especially considering the amount of changes needed in core etc. I'll run this by Tiangolo though, to see what he thinks.

[svlandeg]

These should all be and instead of or, right?