Diamond/blastp updates

[vagkaratzas]

PR checklist

Closes #7350

• This comment contains a description of changes (with reason).
• If you've fixed a bug or added code that should be tested, add tests!
• If you've added a new tool - have you followed the module conventions in the contribution docs
• If necessary, include test data in your PR.
• Remove all TODO statements.
• Emit the versions.yml file.
• Follow the naming conventions.
• Follow the parameters requirements.
• Follow the input/output options guidelines.
• Add a resource label
• Use BioConda and BioContainers if possible to fulfil software requirements.
• Ensure that the test works with either Docker / Singularity. Conda CI tests can be quite flaky:
  • For modules:
    • nf-core modules test <MODULE> --profile docker
    • nf-core modules test <MODULE> --profile singularity
    • nf-core modules test <MODULE> --profile conda
  • For subworkflows:
    • nf-core subworkflows test <SUBWORKFLOW> --profile docker
    • nf-core subworkflows test <SUBWORKFLOW> --profile singularity
    • nf-core subworkflows test <SUBWORKFLOW> --profile conda

[erikrikarddaniel]

Looks great, except for our point of disagreement! ;-)

[vagkaratzas]

@erikrikarddaniel Shall we merge this version? Or wait for a verdict on -outfmt format?

[erikrikarddaniel]

I think it's up to you and me, at least if nobody is actually using it. (I'm for the time being using my own in #metatdenovo.) I'll let you decide, but to reiterate my arguments for having a numerical output specification rather than a suffix:

1. Users of the module are likely users of the tool, so they will be familiar with the different choices for --outfmt.
2. The output format is both a format, e.g. tsv, and content, and at least two output formats are actually the same format, i.e. both blast and taxonomy are tsv.
3. If the param is called ext or similar a user of the module might (I did) guess that one can specify compression by adding a .gz suffix to the format.
4. IMO, it's more explicit to ask for the tool's param value and get the module to return a file with a suffix it chose, than the reverse.
5. I know everything is (should be) specified in the documentation -- but who reads that?
6. I suppose there are other modules with similar problems and I don't know if there's a general recommendation.

[vagkaratzas]

I think it's up to you and me, at least if nobody is actually using it. (I'm for the time being using my own in #metatdenovo.) I'll let you decide, but to reiterate my arguments for having a numerical output specification rather than a suffix:

1. Users of the module are likely users of the tool, so they will be familiar with the different choices for --outfmt.
2. The output format is both a format, e.g. tsv, and content, and at least two output formats are actually the same format, i.e. both blast and taxonomy are tsv.
3. If the param is called ext or similar a user of the module might (I did) guess that one can specify compression by adding a .gz suffix to the format.
4. IMO, it's more explicit to ask for the tool's param value and get the module to return a file with a suffix it chose, than the reverse.
5. I know everything is (should be) specified in the documentation -- but who reads that?
6. I suppose there are other modules with similar problems and I don't know if there's a general recommendation.

Ok, I'm sold. Have a look an feel free to merge if tests pass and you are happy with the changes!

[erikrikarddaniel]

OK, I made two suggestions. I'll accept them and merge.

[erikrikarddaniel]

@vagkaratzas I'm stuck with failing tests due to the runner problems recently. I'll just wait until I need to merge upstream again, and hope they pass then. (I don't know of another way of triggering them... :-S)