Hi <!here>, I want to simplify and improve the tools selection. At the moment all tools are on by default and selected via skip_tools (except for picard collecthtsmetrics). Some tools don't make sense to allow to skip since downstream tools are dependent on. So I made https://github.com/nf-core/seqinspector/pull/192 In which some tools are removed from skip_tools. Relationship from tools and downstream tools is improved. picard collecthtsmetrics is now in skip_tools, as I do think a single system to select tools is easier. That being said, I think it would make more sense from a user perspective to have opt-in tools selection rather than opt-out selection. I have MANY more ideas to improve this, but I think a first step is all tools to be selected/skipped in the same way makes the most sense.

Yes, I fully agree and am happy that you have many ideas along this line (plus, in contrast to me, also the skill to implement them). Maybe using config profiles in conjunction with hidden parameters is indeed a possible way forward? Ben Sherman had suggested that back then already, but to me the config profiles were too tightly linked to infrastructure like container engines. However, after the new prokaryotic profile in #CE8SSJV3N, I start seeing the appeal of using them also for biological settings. Which other ideas do you have?

I'd rather we keep it simple, so for me either go with --tools and have all there (the #CGFUX04HZ way), or a single params for each tools (à la #CE8SSJV3N). But I'd reckon it can quickly be painful if you need to routinely change between sets of tools depending the species/setup/technologies. Config profiles is an idea, for me it is not tied to an infra, for example in #C0110R22NH3 we use #CGRTMASKY to specify genomes at a global scale without having to update the pipeline. Otherwise we could have extra params in the pipeline to specify a set of tools.

On the long term, I would definitively want to have some sort of “meta” setting with limited combinatorial functionality. In the draft that I did back then, which was inspired by #C04CQ1LK7U1, but way outside of the typical nf-core patterns, I tried to recreate the Nextflow’s profile functionality with custom dictionary-style input files that we would have shipped as assets with the pipeline. The motivation for having way for meta settings was exactly what you are describing “_it can quickly be painful if you need to routinely change between sets of tools depending the species/setup/technologies_” There may later be tools in the pipeline that only make sense for Nanopore reads or that depend on a paired-read input etc. With more and more sequencing platforms hitting the market, that alone justifies in my opinion the profiles. Additionally, there may be different QC requirements for different protocols and those profiles could then contain cutoffs for samples getting flagged etc as well? I presume that Nextflow’s config profiles provide exactly the required flexibility to support such use cases.

We agree that on the long term we would all like a way to simplify tool selection. I do think the #C04CQ1LK7U1 way is way too complex, and too outside of nf-core. I do think we need to be careful and not overthink it and keep it simple, and for me, profiles or params would be a simple enough idea