Allow choice of trimmer program

[fgvieira]

Dear all,

not sure if it is supposed to be feature requests in template, but I think it would quite nice to have the option to choose which trimmer to use. For example:

• cutadapt
• fastp
• pear

As I see it, the config could look something like:

trimming:
  activate: false
  tool: cutadapt
  cutadapt:
    # Cutadapt options
    ""
  fastp:
    # Fastp options
    ""
  pear:
    # Pear options
    ""

[christopher-schroeder]

Hey, I can implement this by first creating some snakemake wrappers for fastp and pear. Just because I'm interested: what are the benefits of fastp and pear?

[fgvieira]

I was mostly wondering about the possibility of specifying other adapter programs, since right now the pipeline seems to be pretty much made for cutadapt only (e.g. cutadapt_pipe rule). fastp and pear were just examples of a read trimmer and a read merger for PE, since the latter adds another layer of complexity with a mixture of SE and PE reads that need to be mapped separately and merged. The same applies to some adapter trimming programs, that for PE also output single end reads (if one pair was filtered out), like trimmomatic.

As for the programs, I will probably be interested in several combinations depending on the project:

• adapterremoval: performs read trimming and merging in one step. I've used quite a lot and works fine but can be a bit slow
• fastp or bbduk: seem to be quite fast and have more options (e.g. entropy filtering) and, together with pear, would be equivalent to adapterremoval
• trimmomatic and/or pear: the more "classic" approach for project backward compatibility (if I need to re-run old projects)

[johanneskoester]

The concept of this pipeline is to provide one reasonable choice per task. Hence, for supporting another adapter and trimming tool, we would probably kick out cutadapt. In principle, that is doable, but it would be a breaking change since people configure the pipeline with cutadapt options. Hence, we would have to be a really important reason. Something like 10x faster, or additional options or functionality that is not present in cutadapt. Happy to consider that! I have recently become a fan of fastp, in particular because it can also estimate adapters on the fly, which is very nice from a convenience perspective. That would certainly be an option. Would you say that fastp ticks all boxes for you?

[fgvieira]

I've used fastp quite a bit and will switch to adapterremoval, mainly because it seems fastp is no longer being actively developed. I've found some (minor) bugs and they do not get fixed.
AdapterRemoval, on the other hand, will release soon its version 3 that is faster than fastp!