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

Bad argument help for type of optional argument #438

Open
7 tasks done
alirezatheh opened this issue Aug 2, 2022 · 3 comments
Open
7 tasks done

Bad argument help for type of optional argument #438

alirezatheh opened this issue Aug 2, 2022 · 3 comments
Labels
question Question or problem

Comments

@alirezatheh
Copy link

alirezatheh commented Aug 2, 2022

First Check

  • I added a very descriptive title to this issue.
  • I used the GitHub search to find a similar issue 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

import typer
from typing import Optionaldef main(name: Optional[str] = typer.Argument(None)):
   if name:
       typer.echo(f'Name: {name}')

if __name__ == '__main__':
    typer.run(main)

Description

For optional arguments Typer shows their metavar instead of type in argument help. For above example instead of TEXT we get [NAME] in argument help.

Operating System

macOS

Operating System Details

No response

Typer Version

0.6.1

Python Version

3.10

Additional Context

No response

@alirezatheh alirezatheh added the question Question or problem label Aug 2, 2022
@osintalex
Copy link

osintalex commented Aug 3, 2022

You can manually specify the metavar like this:

import typer
from typing import Optional


def main(name: Optional[str] = typer.Argument(None, metavar='name')):
    if name:
        typer.echo(f'Name: {name}')


if __name__ == '__main__':
    typer.run(main)

@alirezatheh
Copy link
Author

Yes, but this is erasing the problem.

@Noxitu
Copy link

Noxitu commented Sep 6, 2022

I would say that issue is caused by logic in here: https://github.com/tiangolo/typer/blob/7f44e6db6267efa87918e8700212de41a7fbdc3e/typer/rich_utils.py#L367-L377

To reiterate the exact issue - following code:

import sys, typer
sys.argv[1:] = ['--help']

def example(*,
            arg1: int,
            arg2: int = 42,
            arg3: int = typer.Argument(...),
            arg4: int = typer.Argument(42),
            arg5: int = typer.Option(...),
            arg6: int = typer.Option(42),
            arg7: int = typer.Argument(42, metavar='metaarg7'),
            arg8: int = typer.Argument(42, metavar='ARG8'),
        ):
    pass

typer.run(example)

Produces following help message:

Usage: Example.py [OPTIONS] ARG1 ARG3 [ARG4] metaarg7 ARG8

Arguments:
 *    arg1      INTEGER   [default: None] [required]
 *    arg3      INTEGER   [default: None] [required]
      arg4      [ARG4]    [default: 42]
      arg7      metaarg7  [default: 42]
      arg8      INTEGER   [default: 42]

Options:
    --arg2      INTEGER   [default: 42]
 *  --arg5      INTEGER   [default: None] [required]
    --arg6      INTEGER   [default: 42]

The usage example works as intended and documented - for each argument a metavar is displayed.

The issue is in rest of help message. As the code is written - the second column is designed to contain metavar. But due to condition metavar_str == param.name.upper() in most cases it actually contains type name instead of metavar. It is also containing type for all options.

While this condition is core of the issue it probably was added quite reasonably - because metavar column is not really useful. Similarly to OP, I would also prefer changing this column to just always contain type.

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

No branches or pull requests

3 participants