Pipe multiple adatper trimming steps is unsupported when using the python API.

[y9c]

When using the API code in cutadapt, multiple adapter trimming steps will cause error.

For example given a NGS sequencing library with the following scheme:

(p5 adapter)-(UMI)-(inner adapter)-(insert sequence)-(p7 adapter)

We need to cut p5 adapter by -a, then cut UMI sequence by -u, then cut inner adapter again by -a. Since -a is triggered twice, cutadapter will raise an error.

cutadapt/src/cutadapt/report.py

Line 180 in 33df545

assert self.with_adapters[i] is None

[marcelm]

Hi, thanks for reporting this. As you (maybe) know, Cutadapt doesn’t have an official API at the moment, so you’re a bit on your own, but I’m still willing to fix this.

I think it would be a bit nicer to actually allow more than two AdapterCutters and to merge their statistics. I’ll open an alternative PR if you don’t mind.

[y9c]

Thank you @marcelm for helping with this issue. I wrote a simple tool, cutseq (https://github.com/y9c/cutseq), to simplify the adapter trimming steps. It heavily uses the API of cutadapt, and might solve some of the pain points in issue #606.

[marcelm]

I wrote a simple tool, cutseq (https://github.com/y9c/cutseq), to simplify the adapter trimming steps. It heavily uses the API of cutadapt, and might solve some of the pain points in issue #606.

Awesome! Have you considered integrating this into Cutadapt and submitting a PR? It looks similar to what I had in mind.

[y9c]

Thank you very much for your help. I am testing this idea with some real-world data these days, trying to find out the limitations of this API. It meets the requirements of most of the NGS data I have analyzed. It would be great if cutadapt could support this out of the box. I tried to add one new argument for this, but it seems that most of the existing arguments are conflicting with it. Is it okay to suppress all other arguments once the new API is given, or to add a subcommand for cutadapt for this new API?

[marcelm]

I have considered adding subcommands to Cutadapt previously, I suppose that would be the cleanest way. The only problem which complicates things a little is that it should be backwards compatible, that is, the current way of running without a subcommand still needs to work. For simplicity, you could initially suggest a PR that is not backwards compatible and we continue from there.