A community effort to collect a curated set of analysis pipelines built using Nextflow.

nf-core

when you install them via the cli tooling you will get a modules.json file created

it will contain meta information like
```{
  "name": "pipeline",
  "homePage": "",
  "repos": {
    "<https://github.com/nf-core/modules.git>": {
      "modules": {
        "nf-core": {
          "bamutil/clipoverlap": {
            "branch": "master",
            "git_sha": "051e7c60dbdcc5d96ce7814c31426ce776f5319b",
            "installed_by": ["modules"]
          },
          "cat/fastq": {
            "branch": "master",
            "git_sha": "5d28ea7cfaebcfae6f74d1067ea766d8ff19dff3",
            "installed_by": ["modules"]
          },```

this pins the version of the local module source to a particular version of the module in the github repo

when you run a `nf-core modules update` for instance, i belive it compares this to the lastest in the master branch

<https://nf-co.re/docs/tutorials/nf-core_components/adding_modules_to_pipelines>

Yes, as Peter says they are versioned by commit ID. There is not really a human-readable versioning system (ie you can't say "give me samtools v1.19"). 

Some changes to module versions (a change in commit id) may also not materially change the module (could be a meta.yml change, a code formatting change etc) 

Thanks both, I was thinking human versioning not commit hash. This is related a bit to <#C05V42SU8DP> but also tracking down weird behavior in an old pipeline that uses nf-core but hasn't been updated in 2 years

Personally I would be a proponent of a "better" (subjective, the current one is precise but hard to navigate) versioning system - something like using a tag in the meta.yml perhaps - but I think it would be quite tricky to implement and of course it would not have backwards support since older versions would not have implemented it 

I agree, I think galaxy wrappers have an okay versioning system that tracks both the tool version and the wrapper version.

One difficulty is that nf-core module "versions" or implementations are not a 1 to 1 mapping to tool versions. 

And in many cases module implementations would support multiple tool versions if people provided the custom container 

It could be my inexperience but i find pulling module updates can involve a bit of risk unfortunately..

An example is this: At the surface it looks like a module has had its underlying dependency versions bumped..
<https://github.com/nf-core/modules/commit/d40d060ee67b7da7567eb0ecf2149df6d7b8f1f1#diff-f69d237385ea22612326234f7f860d83ce6e41644c906eb52c787dba2f8df810|https://github.com/nf-core/modules/commit/d40d060ee67b7da7567eb0ecf2149df6d7b8f1f1#diff-f69d237385ea22612326234f7f[…]e6e41644c906eb52c787dba2f8df810>

its only when you look closely that you can see the small `-s XS` has been added to the arguments

Luckily, my `nextflow.custom.config` also supplies the same argument causing the pipeline to crash, otherwise it would have surreptitiously altered my workflow in a way i would have found hard to identify

<@U030S4355TJ> Galaxy handles this by having a wrapper version but you are write that it gets complicates if including the software version. I'm mostly interested in versioning the wrapper so I can step back in time through versions to debug an issue. They can be soft tied to software versions.

That's a good example of where some versioning would be useful <@U0974NYS23Y>