-
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
Consider adding PropertiesDefaultProvider implementation #868
Comments
…DefaultProvider` that loads default values from properties file in home directory or specified location.
@Fernal73 to follow up on our conversion about user-editable defaulting: |
@Fernal73 mentions several other tools that provide similar functionality:
|
It's interesting to see how prettier handles config files. There's even
more flexibility.
|
I haven't tested this, but I believe this can be implemented in picocli with multiple passes:
Admittedly, point 4 may not be as simple as that... It may be necessary to inspect the ParseResult and inspect which options were actually specified on the command line, to determine whether to use the value from the command line or from the configuration. |
My understanding of point 4 is that the config file is still a properties file except that its values trump the CLI options. You do bring up an interesting point if you support @files simultaneously. My understanding is that it be treated as an extension of CLI options and used or discarded as per the policy option provided and if respecified (and permitted by policy) , parsed backwards so that the last value specified is the value used. |
How would argument groups resolve this?
|
There is an option to allow overwriting single-value options, and by default picocli does not toggle booleans when they are specified multiple times. However, as I thought some more about this, I don't think the @-file approach is going to work. For one thing, the current That could be fixed, of course, but another (bigger) problem is multi-value options; if the user specifies a few values, and the config file also has one or more values, then the collection or map would end up with the union of both, instead of only the config file values. It may be easier to implement
This would also work for argument groups, although it is more cumbersome to loop over those from the |
I'm inclined to agree that having properties and @files makes it overtly
complex for the command-line user. Implementation-wise, if you treat the
@file as command line expansion, it's pretty much the same.
I was wondering if the three options provided by Pretty Printer can be part
of the API, probably in the Command Line class.
You'd still have multiple passes but it would be simpler.
|
Unfortunately, I had to put aside Picocli for a while to do other stuff. I
haven't come that far along into the documentation. I was trying out the
samples sequentially while working through it.
|
@Fernal73 If there is a feature you want added to picocli, it may be better to raise a new ticket so I won't forget about it. :-) That said, in the spirit of "make common things easy and uncommon things possible", I believe it made sense to add If you have a concrete use case, I would be happy to work through it together to see how we could make it work. It might make sense to then post the resulting program as an example to |
I'm inclined to agree with you. That was my initial reaction when I first discovered Pretty Printer as well. It still requires two passes. I , somehow, got the impression that it'd take four passes. Maybe, I wasn't thinking too clearly. |
This topic may also be a good idea for an article or blog post. I added Advanced Configuration to my list of ideas for articles. |
My experience with command-line tools is limited.
However, the Prettier CLI---ignoring CLI options---is sufficiently similar
to specifying a properties file last in SpotBugs.
That would merit investigating allowing an API setting that has the tool
ignore CLI overriding of parameters stored in a properties object. Would it
be a tri-state flag with another value to ignore all CLI options? (We're
not concerned with positional parameters.)
|
If there is a specific use case you want to investigate together, would you mind creating a separate ticket that outlines what you want to achieve? (We can decide whether this should be added to the picocli API or not once we have arrived at a solution.) |
I don't have a specific use case at the moment. My suggestions are not
easily implementable, in my opinion, unless the property file descriptors
are annotated parameters. That's why you need two passes at this point.
I'm satisfied with the examples listed as prior art in the documentation.
I'll share any more interesting ones should I encounter them.
|
Consider including the
PropertiesDefaultProvider
implementation of theIDefaultValueProvider
interface in the picocli distribution.The text was updated successfully, but these errors were encountered: