-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Ability to define arguments as well (like flags) #378
Comments
Coming from the world of PowerShell, I would like to see an option to define a position for flags that would bind positional arguments. RootCmd.Flags().StringVarP(&Source, "source", "s", "", "Source directory to read from", 0) So the following commands would be valid. myexe --source /src
myexe -s /src
myexe /src All three bind to I'm not sure if that's taboo in the POSIX world, but it makes for a convenient command-line user experience. |
Some progress was made in #284 |
Agreed. I'd go one step further and say there should be the ability to validate types of positional arguments as well. I can already specify that my command takes a --foo argument whose value is of type int, and cobra/pflags will validate the user's input, convert it to an int, and bind it to a corresponding variable. But if I want it as a positional argument I have to roll my own everything. |
Python's built-in argparse library handles this very smoothly. There's no difference at all between a positional and flag-based argument except that one is named eg. "foo" and the other is named "--foo". Everything else - typing, validation, number of values, etc - is exactly the same. And the auto-generated help output documents them all correctly. |
To make it easier for admins and support staff to troubleshoot when the cluster-version operator gets stuck. The SVGs were generated with: $ go build ./hack/cluster-version-util $ mkdir /tmp/release $ oc image extract quay.io/openshift-release-dev/ocp-release:4.1.0[-1] --path /:/tmp/release $ mkdir /tmp/release/manifests $ ./cluster-version-util task-graph /tmp/release | dot -Tsvg >docs/user/tasks-by-number-and-component.svg $ ./cluster-version-util task-graph --parallel flatten-by-number-and-component /tmp/release | dot -Tsvg >docs/user/tasks-flatten-by-number-and-component.svg using: $ dot -V dot - graphviz version 2.30.1 (20170916.1124) I initially put the utility program in cmd/cluster-version-util, moving the main operator to cmd/cluster-version-operator. But Abhinav was concerned about implied support for tooling that is really just intended for exposing internal CVO logic, so this commit puts it under hack/ with a caveat in the main help text. The PATH documentation is stuffed into Use because cobra lacks direct support for named positional arguments [1]. [1]: spf13/cobra#378
To make it easier for admins and support staff to troubleshoot when the cluster-version operator gets stuck. The SVGs were generated with: $ go build ./hack/cluster-version-util $ mkdir /tmp/release $ oc image extract quay.io/openshift-release-dev/ocp-release:4.1.0[-1] --path /:/tmp/release $ mkdir /tmp/release/manifests $ ./cluster-version-util task-graph /tmp/release | dot -Tsvg >docs/user/tasks-by-number-and-component.svg $ ./cluster-version-util task-graph --parallel flatten-by-number-and-component /tmp/release | dot -Tsvg >docs/user/tasks-flatten-by-number-and-component.svg using: $ dot -V dot - graphviz version 2.30.1 (20170916.1124) I initially put the utility program in cmd/cluster-version-util, moving the main operator to cmd/cluster-version-operator. But Abhinav was concerned about implied support for tooling that is really just intended for exposing internal CVO logic, so this commit puts it under hack/ with a caveat in the main help text. The PATH documentation is stuffed into Use because cobra lacks direct support for named positional arguments [1]. [1]: spf13/cobra#378
To make it easier for admins and support staff to troubleshoot when the cluster-version operator gets stuck. The SVGs were generated with: $ go build ./hack/cluster-version-util $ mkdir /tmp/release $ oc image extract quay.io/openshift-release-dev/ocp-release:4.1.0[-1] --path /:/tmp/release $ mkdir /tmp/release/manifests $ ./cluster-version-util task-graph /tmp/release | dot -Tsvg >docs/user/tasks-by-number-and-component.svg $ ./cluster-version-util task-graph --parallel flatten-by-number-and-component /tmp/release | dot -Tsvg >docs/user/tasks-flatten-by-number-and-component.svg using: $ dot -V dot - graphviz version 2.30.1 (20170916.1124) I initially put the utility program in cmd/cluster-version-util, moving the main operator to cmd/cluster-version-operator. But Abhinav was concerned about implied support for tooling that is really just intended for exposing internal CVO logic, so this commit puts it under hack/ with a caveat in the main help text. The PATH documentation is stuffed into Use because cobra lacks direct support for named positional arguments [1]. [1]: spf13/cobra#378
To make it easier for admins and support staff to troubleshoot when the cluster-version operator gets stuck. The SVGs were generated with: $ go build ./hack/cluster-version-util $ mkdir /tmp/release $ oc image extract quay.io/openshift-release-dev/ocp-release:4.1.0[-1] --path /:/tmp/release $ mkdir /tmp/release/manifests $ ./cluster-version-util task-graph /tmp/release | dot -Tsvg >docs/user/tasks-by-number-and-component.svg $ ./cluster-version-util task-graph --parallel flatten-by-number-and-component /tmp/release | dot -Tsvg >docs/user/tasks-flatten-by-number-and-component.svg using: $ dot -V dot - graphviz version 2.30.1 (20170916.1124) I initially put the utility program in cmd/cluster-version-util, moving the main operator to cmd/cluster-version-operator. But Abhinav was concerned about implied support for tooling that is really just intended for exposing internal CVO logic, so this commit puts it under hack/ with a caveat in the main help text. The PATH documentation is stuffed into Use because cobra lacks direct support for named positional arguments [1]. [1]: spf13/cobra#378
This issue is being marked as stale due to a long period of inactivity |
Cobra does not support automatic documentation of positional arguments (see spf13/cobra#378).
++ Following argparse's lead on positional arguments. |
- updated README getting started section to work with new cobra CLI - updated subcommand use section, short descriptions and long descriptions to provide more information - particularly, they now show the positional arguments in "Usage" - added descriptions of the positional arguments in the long description - these are kind of inelegant, see these issues in cobra for why this had to be done - spf13/cobra#395 - spf13/cobra#378
Just started using this package today |
Consistent activity even over a few years with some thoughtful discussion. I think this warrants some extra thought but would definitely need a full proposal as it seems like a potentially large change and the implementation that can conserve backwards compatibility isn't clear. |
I was just trying to figure out how to bind arguments to variable names and came to this issue, so I wanted to add a +1 to show interest. |
Thanks for cobra. It is a really incredible project. Kudos.
In the PHP language there is a similar library quite popular: symfony/console.
In this library you are able to define flags and arguments and access them via names.
This makes development quite readable and convenient.
In cobra arguments are treated as a slice / list instead of defined names. See cobra/cmd/add.go#L47 as an example.
In
symfony/console
you would write something likeand access it like
A matching call would look like
php appname Andy Grunwald
.Did you considered such a behaviour for cobra as well?
What is your opinion about it?
I don`t know much about cobras internal codebase (yet), but i assume this wouldnt be a BC.
I like to hear your opinion and feedback about it.
A few documentation references that might be useful for this:
The text was updated successfully, but these errors were encountered: