Add option to avoid that '[arguments...]' been printed

[tredoe]

Checklist

• Are you running the latest v2 release?
• Did you check the manual for your release?
• Did you perform a search about this feature?

What problem does this solve?

• By default, the help of a command shows the section USAGE with a text like:
  cmd_name [global options] command [command options] [arguments...]
  showing [arguments...] even when your command is not going to use any argument.

Solution description

Add a boolean to indicate that [arguments...] does not been printed.

[coilysiren]

This makes sense to me @tredoe! Although I want to check to see if anyone else in @urfave/cli also thinks this is a good idea? Since I know we've had some concerns about there being too many options.

[AudriusButkevicius]

I think we should just not print that if the app does not support arguments, makes no sense to hide it behind a flag.

[coilysiren]

not print that if the app does not support arguments

is there a way to indicate that an app does not support arguments?

[rliebz]

is there a way to indicate that an app does not support arguments?

Looks like there isn't—we expose the args as a string slice directly off of the flag set. We don't have a way to tell if a user application happens to call that function or not.

Although I want to check to see if anyone else in @urfave/cli also thinks this is a good idea? Since I know we've had some concerns about there being too many options.

I do see this as a common use case, but if we added a configurable field for every common use case, we'd end up with a pretty big list of fields. It's trivial to pass a custom help template in for an App, so I'm in favor of not expanding our interface and letting users set the CustomAppHelpTemplate themselves:

app.CustomAppHelpTemplate = myCustomTemplate

Where myCustomTemplate can be the exact same as cli.AppHelpTemplate, minus the arguments.

[tredoe]

Although I want to check to see if anyone else in @urfave/cli also thinks this is a good idea? Since I know we've had some concerns about there being too many options.

I do see this as a common use case, but if we added a configurable field for every common use case, we'd end up with a pretty big list of fields. It's trivial to pass a custom help template in for an App, so I'm in favor of not expanding our interface and letting users set the CustomAppHelpTemplate themselves:

app.CustomAppHelpTemplate = myCustomTemplate

Where myCustomTemplate can be the exact same as cli.AppHelpTemplate, minus the arguments.

I don't see a problem by having a great list of fields; the standard library has several types with a pretty big list of fields i.e. at the package http.

[rliebz]

HTTP solves a complex problem, as does a CLI library, so the number of knobs we end up with is definitely a product of that complexity. But part of managing software is trying to reduce the amount of complexity we have to deal with. For the http package, how many of those configuration fields have trivial alternatives?

A few of the problems with having too many fields:

• More code for library authors to maintain/test
• Commitment to backward compatibility—we can't easily undo adding an option to a library
• Harder for users to find which configuration fields are relevant for them, versus which ones support niche use cases
• More interactions between options that could be the source of bugs or other unexpected behaviors
• Adding options now limits future design space in a few ways—every new feature has to be compatible with every existing feature, or the usability starts to suffer

[tredoe]

HTTP solves a complex problem, as does a CLI library, so the number of knobs we end up with is definitely a product of that complexity. But part of managing software is trying to reduce the amount of complexity we have to deal with. For the http package, how many of those configuration fields have trivial alternatives?

The type Request from package HTTP was only an example; I have read the standard library so I know that it has many types with a big list of fields; more examples: type header at tar, or type FileHeader at zip.

[tredoe]

A few of the problems with having too many fields:

* More code for library authors to maintain/test
* Commitment to backward compatibility—we can't easily undo adding an option to a library
* More interactions between options that could be the source of bugs or other unexpected behaviors

Your points are valid for whatever code that been added; I mean that it is not exclusive to have "many fields" into a structure.

* Harder for users to find which configuration fields are relevant for them, versus which ones support niche use cases

It is solved with the documentation.

* Adding options now limits future design space in a few ways—every new feature has to be compatible with every existing feature, or the usability starts to suffer

This was solved a long time ago with versioning software.

[coilysiren]

See also => #1074

[coilysiren]

I'm making this as help wanted primarily because the desired solution almost certainly includes the work required for this issue => #1074

[stale]

This issue or PR has been automatically marked as stale because it has not had recent activity. Please add a comment bumping this if you're still interested in it's resolution! Thanks for your help, please let us know if you need anything else.

[stale]

Closing this as it has become stale.