Skip to content
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

Factor out ArgumentDefinition classes and refactor CommandLineArgumentParser. #133

Merged
merged 4 commits into from
Oct 18, 2018

Conversation

cmnbroad
Copy link
Collaborator

@cmnbroad cmnbroad commented Mar 12, 2018

CommandLineArgumentParser refactoring. Extract classes for positional and named argument definitions with common ArgumentDefinition base class. All GATK and Picard tests have passed with these changes (Picard requires no source changes, GATK changes corresponding to the gatherFieldValuesOfType changesr are in broadinstitute/gatk#4523).

Fixes:

Additional fixes:

  • dangling mutex arguments are not reported/rejected in some cases (some doc tests had these and had to be changed accordingly)
  • positional arguments cannot be populated from an expansion file
  • tagged arguments cannot be populated from an expansion file
  • gatherFieldValuesOfType (now renamed gatherArgumentValuesOfType) didn’t return values from plugins or positional arguments
  • minor command line and usage display formatting issues

Prerequisite for:

Existing tests will be refactored is a separate PR.

@cmnbroad cmnbroad requested a review from jonn-smith March 12, 2018 19:44
@cmnbroad
Copy link
Collaborator Author

For @jonn-smith (or @droazen) or whoever can get to it.

@jonn-smith jonn-smith self-assigned this Mar 19, 2018
Copy link
Contributor

@jonn-smith jonn-smith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments / minor changes.

Looks pretty good. There was a lot of code, so I'm a little worried I didn't see into some details.

I found the parts where you grab a base field collection and modify it in place a little confusing, but it makes sense.

}
} catch (final Exception ex) {
// Note: I assume this catches Exception to handle the case where the type is not instantiable
// TODO: Can't we just throw when this happens ??
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering the same thing as this TODO. Should we still try to run if the field can't be set properly?

Copy link
Collaborator Author

@cmnbroad cmnbroad Mar 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parser tries to auto-create a collection instance of the declared type if the argument field doesn't already have one. If that fails, it catches Exception and falls back to trying to create an ArrayList. If not for the backward compatibility issue, I would require the coder to create the collection, and just let it throw. But I suspect there is code that relies on this behavior. I'll remove that TODO and fix the comment (I originally added it as a note to myself when I was refactoring).

* @return never {@code null}.
*/
@SuppressWarnings({"unchecked","rawtypes"})
protected static String getOptions(final Class<?> clazz) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it maybe worth having a way to include some example options for String arguments as well? The implementation would need to fill out this example string.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That might be a good idea, but I'd prefer not to introduce any additional new features is a separate PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Can you add this in as a new issue (if you haven't already)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done #144. For the record, I also changed the getOptions method from a static method to an instance method to make it easier to implement this request when we do so, and renamed it to getOptionsAsDisplayString to better reflect what it does.

@codecov-io
Copy link

codecov-io commented Oct 15, 2018

Codecov Report

Merging #133 into master will increase coverage by 0.49%.
The diff coverage is 80.72%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #133      +/-   ##
============================================
+ Coverage     76.07%   76.56%   +0.49%     
- Complexity      593      669      +76     
============================================
  Files            22       26       +4     
  Lines          2215     2296      +81     
  Branches        457      455       -2     
============================================
+ Hits           1685     1758      +73     
- Misses          352      366      +14     
+ Partials        178      172       -6
Impacted Files Coverage Δ Complexity Δ
...institute/barclay/argparser/CommandLineParser.java 0% <ø> (-78.73%) 0 <0> (-17)
...titute/barclay/argparser/TaggedArgumentParser.java 85.1% <100%> (+0.16%) 22 <1> (+1) ⬆️
...lay/argparser/LegacyCommandLineArgumentParser.java 75.91% <50%> (-0.16%) 128 <6> (ø)
...arclay/argparser/PositionalArgumentDefinition.java 69.81% <69.81%> (ø) 11 <11> (?)
...nstitute/barclay/argparser/ArgumentDefinition.java 70.43% <70.43%> (ø) 26 <26> (?)
...titute/barclay/help/DefaultDocWorkUnitHandler.java 76.87% <77.77%> (+4.95%) 74 <24> (-1) ⬇️
...ute/barclay/argparser/NamedArgumentDefinition.java 78.59% <78.59%> (ø) 122 <122> (?)
.../barclay/argparser/CommandLineParserUtilities.java 83.33% <83.33%> (ø) 2 <2> (?)
...e/barclay/argparser/CommandLineArgumentParser.java 89.61% <93.26%> (+6.73%) 115 <92> (-68) ⬇️
...titute/barclay/argparser/CommandLineException.java 47.05% <0%> (-2.95%) 2% <0%> (ø)
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9417229...ef82b6e. Read the comment docs.

@cmnbroad
Copy link
Collaborator Author

@jonn-smith I think I responded to all your comments.

Copy link
Contributor

@jonn-smith jonn-smith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One minor bookkeeping request (adding in an issue if it doesn't already exist for my comment in ArgumentDefinition.java).

After that it looks good to merge.

* @return never {@code null}.
*/
@SuppressWarnings({"unchecked","rawtypes"})
protected static String getOptions(final Class<?> clazz) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Can you add this in as a new issue (if you haven't already)?

@jonn-smith
Copy link
Contributor

@cmnbroad Looks good! Merge away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants