-
Notifications
You must be signed in to change notification settings - Fork 37
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
Allowing multiple valued @options via 'new' annotation method? #269
Comments
Your second example should work, or I should say your second example is intended to work. Try with one argument; I believe there may be a bug with zero-argument commands that have options. I haven't had a chance to isolate and fix yet. |
I did some brief tests and could only get binary / valueless options to work. This is a bug. |
Hi Greg, Thanks for the investigation and time. Would you prefer I open a new, more targeted issue addressing this? |
It is not a good idea to have an argument and an option with the same name. |
I don't recall if this bug has been fixed; I did some work on options in the Annotated Command library some time back. It would be better to track issues with that library in its own queue. |
I am unsure if this issue belongs here, or in the consolidation/robo repository. Apologies if I have chosen incorrectly.
Following the 'legacy' hint in the documentation, we are attempting to migrate our @commands in Robo from the 'Legacy Annotated Command Methods' to the current method.
We are struggling with how to port @option items that allow multiple values. Legacy method:
This allowed the user to specify as many branches as desired (while also defining a default option) via multiple switches. It also added '(multiple values allowed)' to the --help text.
One initial effort to port this was to 'type' the function argument in the method signature as array:
this only resulted in a type validation error, as the framework passes a non-array.
How should this desired behavior be defined using the new annotation method? Is it possible, or In the 'new' method are multiple valued options only achievable using separators (--branch=dev,prod) and manual parsing (e.g. explode) within the command?
Warm regards, and many thanks for your efforts.
The text was updated successfully, but these errors were encountered: