read_qc subworkflow

[chrisAta]

Adding subworkflow that performs read QC using two modules:

• fastp (imported from nf-core, modified slightly to remove parameters we don't need)
• seqtk/seq (imported from nf-core)

[KateSakharova]

General question. If you took a module from nf-core should it be under nf-core folder rather than ebi-metagenomics?

[chrisAta]

General question. If you took a module from nf-core should it be under nf-core folder rather than ebi-metagenomics?

Good question... I think from what @mberacochea told me before you can't have modules from more than one 'nf-core repo' for a custom modules repo, so I think the nf-core tools would break if we tried. For example trying to install nf-core/fastp:

nf-core modules install fastp

                                          ,--./,-.
          ___     __   __   __   ___     /,-._.--~\
    |\ | |__  __ /  ` /  \ |__) |__         }  {
    | \| |       \__, \__/ |  \ |___     \`-._,-`-,
                                          `._,._,'

    nf-core/tools version 2.10.dev0 - https://nf-co.re


ERROR    You cannot install a fastp in a clone of nf-core/modules  

And I think some of the nf-core tools look at org_path in .nf-core.yml to know where to look for modules, and in this repo we have it set to ebi-metagenomics, so if we manually created an nf-core directory I don't think it would look there anyway

[KateSakharova]

@chrisAta OK, I see.
In my vision we should definetely distinguish nf-core taken tools and our self-written. We need to mark it somehow or create a symlink maybe?
I'm just thinking it can be a case we bump into very BAD nf-core written module and we want to re-create it completely from our side (less likly but who knows...) what we should do?
Having nf-core subfolder can resolve it

Those are just are my thoughts for future. No need to do anything now :)

[chrisAta]

@chrisAta OK, I see. In my vision we should definetely distinguish nf-core taken tools and our self-written. We need to mark it somehow or create a symlink maybe? I'm just thinking it can be a case we bump into very BAD nf-core written module and we want to re-create it completely from our side (less likly but who knows...) what we should do? Having nf-core subfolder can resolve it

Those are just are my thoughts for future. No need to do anything now :)

Yes I completely agree - would be nice to have a more obvious and defined way for making it clear we didn't build a module from scratch 😄 Something to discuss in near future

[mberacochea]

@chrisAta OK, I see. In my vision we should definetely distinguish nf-core taken tools and our self-written. We need to mark it somehow or create a symlink maybe? I'm just thinking it can be a case we bump into very BAD nf-core written module and we want to re-create it completely from our side (less likly but who knows...) what we should do? Having nf-core subfolder can resolve it

Those are just are my thoughts for future. No need to do anything now :)

I agree, copying modules over is far from ideal but it's the best solution we have ATM. nf-core tools doesn't support subworkflows with modules from different repos (nf-core/tools#1927). The other option would be to symlink the modules, but that would create some issues down the road and will be tricky to maintain and deploy.

The best solution would be for subworkflows to support modules from nf-core and custom repos.

[mberacochea]

Great stuff @chrisAta .. I've added some minor comments.

[chrisAta]

Great stuff @chrisAta .. I've added some minor comments.

All done! Thanks for the review 😄

[mberacochea]

One last bit.. the nextflow.config file for the subworkflow.

[mberacochea]

Great stuff

[KateSakharova]

Thank you Chris!