Add --version to NfCoreTemplate

[SamStudio8]

As briefly discussed in the nf-core Slack, I was recently asked by a user "how do I know what version I have of your workflow?" which seemed like a simple question!

I was surprised to find that nextflow info <workflow> does not provide this (but I can imagine why). nextflow info does list and show the current revision, which is fine if you've checked out a specific tag but not useful for users who have just pulled with nextflow run <workflow> without -r.

The workflow.manifest.version is used by nf-core's template to populate an email message, and the logo function; but I wonder whether a more familiar --version-like invocation of a pipeline to print out version information might also be useful?

The WorkflowMain.version function definition in this PR will cook up a version identifier using both the manifest, and the workflow commitId (if available), it might be that this function should move to NfcoreTemplate instead to allow it to be used in the message and logo functions too.

Notably this would prevent any pipeline from using version as a parameter, so might be one to think about...! Thoughts welcome!

Examples below:

nf-core-hoot % nextflow run main.nf --version
N E X T F L O W  ~  version 22.04.3
Launching `main.nf` [cranky_koch] DSL2 - revision: c8865a20a8
nf-core/hoot v1.0dev

% nextflow run local/nf-core-hoot --version
N E X T F L O W  ~  version 22.04.3
Launching `/Users/Sam.Nicholls/git/tools/nf-core-hoot` [disturbed_becquerel] DSL2 - revision: d8f596bdf1 [master]
nf-core/hoot v1.0dev-gd8f596b

PR checklist

• This comment contains a description of changes (with reason)
• CHANGELOG.md is updated
• If you've fixed a bug or added code that should be tested, add tests!
• Documentation in docs is updated

[mirpedrol]

Hi @SamStudio8, that's a good solution!
Do you think it would be worth allowing the developer to skip this when creating the pipeline template? In case they want to use their own params.version.
As an example, #1551 made the nf-core logo optional, it should be something like that.

[SamStudio8]

Hi @mirpedrol! I think if this were to get added to the template it should be all-or-nothing to ensure it provides predictable behaviour. That is, we should either add it to the template and force all pipelines to make use of --version; or not add it at all.

[SamStudio8]

For what it's worth, pipelines cannot use their own --version with the template as it stands anyway, as it will abort the pipeline with the following message:

ERROR: You used a core Nextflow option with two hyphens: '--version'. Please resubmit with '-version'

(I've just had to patch out this very thing to make this PR work)

[codecov]

Codecov Report

Merging #1951 (960e5cf) into dev (b70ba88) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev    #1951   +/-   ##
=======================================
  Coverage   63.91%   63.91%           
=======================================
  Files          43       43           
  Lines        5509     5509           
=======================================
  Hits         3521     3521           
  Misses       1988     1988           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[mashehu]

Hi, sorry for the long pause. I think it might lead to some confusion that -version returns something completely different to --version. How about we call this parameter --pipeline-version?

[SamStudio8]

No worries @mashehu!

nextflow run does not actually support the -version argument so I'd suggest there is enough of a distinction between nextflow -version and nextflow run <pipe> --version:

$ nextflow run -version
Unknown option: -version -- Check the available commands and options and syntax with 'help'

Either way, I'd push for --version as this is a commonly understood argument for getting the version of something that typical users would expect to find. I think if someone needs to inspect the help to find out what the argument is, it would defeat the objective of including it at all (the --help may as well print the version).

[maxulysse]

I'd go for --version as well, as every - params` with a single hyphen is a Nextflow one.

[mirpedrol]

Besides the naming discussion, is this PR ready? Or still WIP? I've tested it and works nicely 🙂

[SamStudio8]

Hi @mirpedrol, I was thinking of moving this version function to the NfcoreTemplate.groovy so it could be used in the other functions that refer to the workflow version (email, logo)? WorkflowMain already calls functions in NfcoreTemplate so it would not be unusual. What do you think?

[SamStudio8]

@mirpedrol I've just bumped this to follow up on my previous suggestion, I think it makes sense for anything reporting the workflow version to report the same thing. Let me know what you think, I can always revert the commit.

[mirpedrol]

LGTM!
And I also think it makes sense moving the function to NfcoreTemplate. I like how it prints the version together with the logo :)

[SamStudio8]

Thanks @mirpedrol! I've rebased and squashed so I think this is ready for CI 🚀

[SamStudio8]

I don't seem to have perms to poke the CI pipe but we seem to have been caught up in the API rate limit!

[mirpedrol]

all green now! 🚀

[matthdsm]

me likey!