-
Notifications
You must be signed in to change notification settings - Fork 418
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
Support repeating composite arguments (was: Parameter options/modifiers) #358
Comments
Very interesting use case! I haven't considered this before. So essentially you have repeating composite arguments. ( I may actually change the name of the ticket to this.) The short answer is that picocli, as of version 3.0.0-alpha-6, does not support functionality like this. I I need to think about this for a while. |
Brainstorming a bit: one idea is to introduce a new @Command(name = "print")
class PrintCommand {
enum PaperFormat { A1, A2, A3, A4 }
@Option(names = "--paper")
PaperFormat format;
@CompositePositionalParam(index = "0..*")
Document[] documents;
}
@Composite
class Document {
@Parameters(index = "0", arity = "1")
File file;
@Option(names = {"-c", "--count"})
int count = 1; // the default
enum Rotate { left, right, straight }
@Option(names = "--rotate")
Rotate rotate = Rotate.straight; // the default
} |
Composite positional parameters is a good idea. I would rather keep naming consistent, and named it Modifiers ideaI was also thinking about modifiers vs options. Where modifier would apply to all further parameters, and is reset by Depends on use case, but it might be good to leave a choice to an application user, instead of application developer or library developer (forced style). One idea is to introduce @Option(names = {"-c", "--count"}, modifier_names = {"---count"})
int count = 1; // the default So, command-line application user can use Modifier reset functionalityOne idea to implement reset functionality is to use
So, it might be useful to have a possibility to specify reset names for an option, ie.: @Option(
names = {"--rotate"},
modifier_names = {"---rotate"},
modifier_reset_names = { "---reset-rotate", "--!rotate" }
)
Rotate rotate = Rotate.straight; Or, it could be specified by a replacement regex rule, which would generate @Composite(modifiers_maker = new Replace("---([-a-zA-Z]+)", "---reset-$1"))
class Document Also, it's not only about easier usage, but about aesthetics of commands. |
I agree that I think that it makes sense for picocli to provide generic support for composite options and positional parameters but some of what you describe, like the dynamic defaulting behavior, will likely have to be implemented in the application. Currently, the Then, given input like your original example:
I imagine picocli could parse this and provide the application with these
The application then has enough information to apply its defaulting rules. Thoughts? |
Great. It would be a very useful feature for applications, which take multiple inputs and need to support extra options for individual inputs. My use-case is different, but very similar. I work on graphical tool, which combines multiple (1 .. n) inputs and produces an output. All these inputs should support individual options.
You're right. Currently, it's bit of over-thinking/over-engineering to have dynamic defaulting behavior. It would be an extra feature, but it's not essential to full-fill use-case: user can repeat arguments, or dynamic defaulting behavior will be implemented in application.
I would rather separate it to an follow-up feature request, as it's an extra, and isn't essential to fulfill use-case. I see, that you've already created #359 for it. |
Related: a simpler but similar use case is this groovy command line tool:
This command can accept repeating groups of |
Another use case for composite parameters was raised by @bbottema on #434 (resulting in workaround #441). The use case is a console interface for an email client, with options that have many parameters, like this:
Question for @bbottema: are all elements in such composite parameters mandatory? Or would you want to support for example omitting the |
That's the synopsis, but the invocation currently is:
In case it keeps working like this, then the answer to your question depends on the implementation of how arguments are referenced after parsing: If these composite option values would have to be predefined (ie. a class with declared fields), then it would be useful and feasible to have optional fields (being referable by name). However, in my use case I prefer to leave to the composition unbounded (ie. an array of arbitrary number of types of mandatory parameter values). This is because I'm generating the composite signatures in runtime using reflection. To illustrate, I prefer: { String.class, Integer.class, Boolean.class } over: class CompositeOptionValue {
String a;
Integer b;
Boolean c;
} Of course, you could work with a Map here: "a" : String.class,
"b" : Integer.class,
"c" : Boolean.class In this case the parsed arguments can be referenced by name but also generated by name in run time, in which case optional values are workable again. Without named arguments, it will become impossible to know which parameters of a java In general though, I have to add that I don't have many optional parameters, because that would imply that there is a different need than the API provides and I would simply add an overloaded more succinct version with that parameter left out. |
Picocli 4.0.0-alpha-1 has been released which includes support for repeating composite groups. Please try this and provide feedback. We can still make changes. What do you think of the annotations API? What about the programmatic API? Does it work as expected? Are the input validation error messages correct and clear? Is the documentation clear and complete? Anything you want to change or improve? Any other feedback? |
Picocli supports mixing options and parameters: http://picocli.info/#_mixing_options_and_positional_parameters
I would like to know what options have been specified before certain parameter. Consider such command:
Where:
--paper
is an global option,--count
and--rotate
are "local" options, or parameter modifiers,--
reset local options.So, that command would evaluate to:
paper = A4
,A.pdf
:count = default, rotate = default
,B.pdf
:count = 3, rotate = default
,C.pdf
:count = 3, rotate = left
,D.pdf
:count = default, rotate = default
,E.pdf
:count = default, rotate = right
.Is there support for such things in picocli?
The text was updated successfully, but these errors were encountered: