-
-
Notifications
You must be signed in to change notification settings - Fork 680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Show help items in order of definition #944
Conversation
📝 Docs preview for commit 7393626 at: https://304fedd0.typertiangolo.pages.dev Modified Pages |
"""Returns a list of subcommand names. | ||
Note that in Click's Group class, these are sorted. | ||
In Typer, we wish to maintain the original order of creation (cf Issue #933)""" | ||
return [n for n, c in self.commands.items()] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that we can't just
return self.commands
here as self.commands
is actually a MutableMapping[str, Command]
and so this wouldn't pass type checks.
As such, I'm unsure why "top" is now being shown in the help first. I'll investigate further and will keep this in draft while doing so. |
📝 Docs preview for commit c7cccd7 at: https://b7401c17.typertiangolo.pages.dev Modified Pages |
Ok, so we need to consider how subgroups are treated here versus commands. Assume the following simplified code:
Then run
and you'll get
So even though Now, why is this? Because of the code in
So @tiangolo: are we happy with registered commands taking precedence of registered groups, with this PR? If so, we can have this PR as is and the changes to If we want to consider the order in which groups vs commands are declared in the input source (a.k.a. keep "sub" as first in the example above), then we're likely looking at a bigger refactor because we'll have to rethink how |
|
||
## Sorting of the commands | ||
|
||
Note that by design, **Typer** shows the commands in the order they've been declared. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: if we keep the current behavour of command/group sorting, then we probably want to comment on that in the docs as well, because otherwise it may be confusing. I can add this after we decide how to move forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! 🚀 🎉
@svlandeg feel free to merge it. 😎
sorry, does this work? I'm seeing sorted commands. import typer
print(typer.__version__)
app = typer.Typer(no_args_is_help=True)
@app.command()
def say(what: str):
"""Say it"""
typer.echo(f"say {what}")
@app.command()
def hi():
"""Say hi to pup"""
typer.echo("🐶 says: woof!")
if __name__ == "__main__":
app() Output:
|
Hi @liquidcarbon, This PR was merged on Aug 26, while v. 0.12.5 was released on Aug 24. So this PR hasn't yet made it to the latest release of |
This is now available in release 0.13.0 🎉 |
Fixes #933
Click's
Group
class specifically orders the items alphabetically:For
TyperGroup
, we override this behaviour and remove thesorted
function. This works, because during creation of the group, the commands are kept in a list as they get declared, soself.commands
has the original order.