Anchor barcodes during demultiplexing

[vaamb]

Follow up of the pull request #57

Allow to anchor barcodes for demultiplexing, which can be useful when used in combination with the --cut parameter.

Overview of the kind of problems it can solve:
When doing metabarcoding, it is sometimes advised to add a short poly-N (around 5) at the beginning of the sequence to increase Illumina sequence discrimination in the early phases of sequencing.
However, cutadapt does not anchor barcodes by default, meaning that using cutadapt on sequence "RCODEacgt" with the barcode "BARCODE" will result in the demultiplexed sequence "acgt".
Given enough sequences, and the use of numerous short barcodes (such as an Illumina index of 8 bases) this can lead to the wrong assignation of many sequences, hindering downstream processes.
One simple solution is to first remove the poly-N (using the --cut option) and using anchored barcodes.
While it is possible to anchor this for each barcode individually by adding a ^ before the barcode, this can be cumbersome. This pull request uses cutadapt ^file:* option to anchor all the barcodes at the same time

[colinvwood]

Hello @vaamb,

Thanks for the contribution. I want to make I understand the use case here. Does the following represent the type of situation you're trying to cover?

1. barcodes are placed (e.g.) at the 5' end of a sequence
2. a poly-N sequence is placed upstream of the barcode: 5' NNN BARCODE SEQUENCE 3'
3. trimming the barcode using cutadapt's standard 5' end trim is too risky because barcodes are short and may be a couple of mismatches away from a sub sequence of the true biological read, possibly resulting in mis trimming or mis demultiplexing
4. anchoring is thus desirable (this PR)
5. to anchor however, we need cut to get the N's out of the way so that the barcode actually begins the sequence (other PR)

[lizgehret]

Hey @vaamb - we'll need to bump this to next release if we don't hear back from you by EOD tomorrow. Thanks!

[vaamb]

Hello @colinvwood,

This is indeed the use case I have.
The other PR (the cut one) fixed most of my mis-demultiplexing issues as the "NNNNN" at the beginning of the sequence were interpreted by cutadapt as possible barcodes. This PR allowed to further reduced the mis-demultiplexing issue (although to a lesser extent) as well as improve the processing speed.

For the record, barcodes were anchored by default in cutadapt prior to version 2.0

[vaamb]

Hello @colinvwood,

Sorry for the time it took, I totally rewrote my PR over in order to rebase it on main and take into account everything that was said for the PR #57
I think I added enough tests but should you need some more, don't hesitate to tell me.

[colinvwood]

I would also like to see a test proving that anchoring behaves as expected when applied to the reverse reads.

[colinvwood]

Hey @vaamb just fyi we have a release planned for dec. 11 in case you were trying to get this merged in this cycle

[vaamb]

Hi @colinvwood
I added a test for forward and reverse anchoring and another one to make sure that reverse barcode is required when anchoring in the case of non mixed orientation

[colinvwood]

Thanks for all your work on this @vaamb, the tests look good to go.