Skip to content
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

Argument(metavar="MY_ARG") has different meaning for the arguments panel compared to the usage text or the non-rich help output #1156

Open
7 tasks done
JacobKochems opened this issue Feb 12, 2025 · 1 comment

Comments

@JacobKochems
Copy link

Discussed in #646

Originally posted by JacobKochems August 1, 2023
First of all, thanks to all who are involved, especially to the creator, for your hard work. It's really a cool project.

First Check

  • I added a very descriptive title here.
  • I used the GitHub search to find a similar question and didn't find it.
  • I searched the Typer documentation, with the integrated search.
  • I already searched in Google "How to X in Typer" and didn't find any information.
  • I already read and followed all the tutorial in the docs and didn't find an answer.
  • I already checked if it is not related to Typer but to Click.

Commit to Help

  • I commit to help with one of those options 👆

Example Code

# mre.py  (minimal reproducible example)

import typer
from typing_extensions import Annotated

app = typer.Typer()


@app.command()
def show(user: Annotated[str, typer.Argument(metavar="MY_ARG")]):
    """Show user."""
    typer.echo(f"[stub] show user: {user}")


if __name__ == '__main__':
    app()

Description

Observed Behavior

With rich installed, calling the above example with python mre.py --help produces the following help output:

Usage: mre.py [OPTIONS] MY_ARG                                                                                                                                                                  
                                                                                                                                                                                                   
 Show user.                                                                                                                                                                                        
                                                                                                                                                                                                   
╭─ Arguments ──────────────────────────────────────────────────
│ *    user      MY_ARG  [default: None] [required]
╰────────────────────────────────────────────────────────
╭─ Options ───────────────────────────────────────────────────
│ --install-completion  Install completion for the current shell.
│ --show-completion     Show completion for the current shell, to copy it or customize the installation.
│ --help                Show this message and exit.
╰────────────────────────────────────────────────────────

In the usage text MY_ARG stands for the argument name but in the argument panel it stands for the argument type, thereby rendering this solution: #230 (comment) invalid for rich help text output.
Moreover, the argument type can only be set/overwritten by metavar if metavar!="user".upper(), which seems to be related to #438.

Without rich being installed the above example looks like this:

Usage: mre.py [OPTIONS] MY_ARG

  Show user.

Arguments:
  MY_ARG  [required]

Options:
  --install-completion  Install completion for the current shell.
  --show-completion     Show completion for the current shell, to copy it or
                        customize the installation.
  --help                Show this message and exit.

and works as expected: in both places MY_ARG stands for the argument name and the argument type vanishes.

Expected Behavior

I expect the respective argument names user/USER to be replaced by metavar regardless of output mode and the argument type to stay unchanged.

Operating System

Linux

Operating System Details

No response

Typer Version

0.9.0

Python Version

3.9.2

Additional Context

No response

@JacobKochems
Copy link
Author

Update:
The issue is still present in version: 0.15.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant