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

Add depth --excl-flags et al flags #1718

Merged
merged 2 commits into from Sep 22, 2022

Conversation

jkbonfield
Copy link
Contributor

The --excl-flags option is a synonym for -G, and also added --incl-flags and --require-flags to match view logic.
Also fixed a minor -H duplication in the usage statement. Fixes #1702.

(Apologies for the late arrival of the PR. I thought I'd already made it,)

This matches the behaviour of "view --excl-flags", and is similar to
"mpileup --excl-flags".  The difference is that mpileup SETs the flags
while depth/view OR additional fields onto the flags.  (Depth also has
-g to AND-off the default exclude flags, which is not needed in view
as the default is zero.) Also clarify -g in the usage indicating this
is still the code to filter-out rather than filter-in and avoid
confusion over "view --incl-flags".

This commit does not add a --incl-flags option.

Also removed a duplicate -H usage option.

Fixes samtools#1702
These match the logic seen in samtools view of needing at least 1 flag
and needing all flags to be set.
@whitwham whitwham merged commit 33b293b into samtools:develop Sep 22, 2022
fprintf(fp, " Add specified flags to the default filter-out flag list\n");
fprintf(fp, " [UNMAP,SECONDARY,QCFAIL,DUP]\n");
fprintf(fp, " --incl-flags FLAGS\n");
fprintf(fp, " Only inclue records with at least one the FLAGs present [0]\n");
Copy link
Member

Choose a reason for hiding this comment

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

Only incluDe records… (and similarly below).

Also other subcommands accept both ‑‑excl‑flags/‑‑incl‑flags and ‑‑exclude‑flags/‑‑include‑flags.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops. I'll fix the typo.

The include vs incl abbreviation is specific to view. Depth, mpileup, coverage and consensus all have incl-flags but not include-flags. So I think going with the common trend is the right thing here.

Copy link
Member

Choose a reason for hiding this comment

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

The long option additions to view are the most recent, so I suppose I was trying to introduce a trend of enabling the full spellings. (And hadn't got around to making a PR accepting both inter­change­ably in the other subcommands.)

But what I really wanted to introduce was samtools/htslib#1361, which would allow unifying all this as a single option instead of adding all these variants to the various subcommands. However the maintainers have carried on adding variant options instead. If there seemed to be interest in the unified approach, I would be happy to dust it off.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's because 1361 is draft. When I asked how it was going you said it's still undergoing refactoring, so it's unfair to complain we haven't adopted those policies yet and "have carried on adding variant options instead".

Besides, I always viewed that PR as an additional nomenclature (not "instead") and all new commands would be supporting both old and new syntax for consistency.

Copy link
Member

Choose a reason for hiding this comment

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

I said “seemed to be interest in [the alternative approach of a unified option]”, not “adopted”.

Certainly I proposed the unified approach as a more user-friendly and mnemonic alternative to further adding to the plethora of flag-filtering options and therefore not adding new variant options (while preserving the already existing ones, of course).

By approving PRs continuing to add to the plethora of flag-filtering options, the maintainers have implicitly signalled that they are not particularly interested in the proposed alternative user interface. Thanks for clarifying.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The --incl-flags and --require-flags are entirely new to this subcommand, so this part at least was adding new features. Given they're new options they obviously needed some name, and making them compatible with other existing options seemed logical rather than exacerbating things with yet another mnemonic. Please do not take it as a signal that the unified approach is not desired, but as this arrived first there really was no question as to their naming.

jkbonfield added a commit to jkbonfield/samtools that referenced this pull request Sep 22, 2022
whitwham pushed a commit that referenced this pull request Sep 22, 2022
c4chris pushed a commit to sib-swiss/samtools that referenced this pull request Jan 11, 2023
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.

Contrived parameters in samtools depth?
3 participants