Skip to content

Improve CLI help #733

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

Closed
xarx00 opened this issue Mar 5, 2019 · 3 comments
Closed

Improve CLI help #733

xarx00 opened this issue Mar 5, 2019 · 3 comments
Labels

Comments

@xarx00
Copy link
Contributor

xarx00 commented Mar 5, 2019

Description of the problem, including code/CLI snippet

There's a lot of issues for the CLI help, which makes it difficult to use the CLI at all. Some of them have been already reported:

  1. --help does not work properly on sub-commands (gitlab CLI --help not working as expected #381, mostly resolved by Re-enable command specific help messages #732)
  2. The usage and help outputs are unreadable, ugly and confusing (CLI: List objects vertically #456, [CLI] improve CLI usage output #545, still unresolved)

But there are others, for instance:

  1. When wrong arguments are used (e.g. gitlab group list -x), general usage (for gitlab) is printed by gitlab CLI instead of specific usage for the used action (i.e. gitlab group list).

Gitlab uses argparse for argument parsing and help output. Most of these problems (2. and 3. in particular) seem to be caused by the limitations of the argparse library. I was trying to persuade argparse to provide better help, but I was not able to do that. Most of this bad behaviour is hard-coded in the library, and cannot be changed. The public API is limited, the rest of the API "are considered implementation details".

I'm not an expert for argparse, so I may be wrong, but the help seems to me unfixable while it is based on argparse. Instead I suggest switching to click. I was playing with click, and I was able to configure it so that its help output looks very good even for a script like gitlab. See demo comparison.zip, that compares help output of argparse and click in various situations. In the comparison, note:

  • argparse output is appropriate to the arguments in all tests but the last two.

  • argparse output looks confusing especially when there are lots of commands (I've counted 27 rows of commands on 80 character console, and this list is printed twice)

  • argparse output cannot be customized

  • click output looks more standard

  • click output can be simply customized (as seen e.g. in demo_click2.py)

Resume

I'd like to know your opinion on this suggested change. I won't be doing anything concerning the migration towards click untill it is clear that the change will be welcome.

Specifications

  • python-gitlab version: 1.8.0
@gpocentek
Copy link
Contributor

Hi @xarx00

I started looking at other solutions for argument parsing a few days ago but didn't have time to test.

I don't have experience at all with click but we probably reached the limits of argparse as you mentioned.

I say +1 to switching to something else.

@xarx00
Copy link
Contributor Author

xarx00 commented Mar 6, 2019

Some reference: https://realpython.com/comparing-python-command-line-parsing-libraries-argparse-docopt-click/.

I have an experience with Docopt (also tested in the link), and while it is a good library, it is suited for small scripts. I have looked also on other options suggested in discussions, but Click came out as a clean winner.

@nejch
Copy link
Member

nejch commented Aug 2, 2022

Since we now have #456 fixed, and we have #1461 to discuss our plans to switch to click, I'd say we can maybe close this one since this is quite old and continue discussion in the other issue where there is more activity. Feel free to reopen @xarx00 if this is still something you're still interested in implementing in 2022 - though obviously this will take quite a bit of work.

@nejch nejch closed this as not planned Won't fix, can't repro, duplicate, stale Aug 2, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants