Just to add some more comments - this is already a really great start. What would be great to have here is to be able to select certain bits of the template and leave others out, e.g. the CI part is tied to Github Actions whereas people might have to run CI for their "nf-core harmonized" pipelines internally on their own CI. So would be great to pass some parameters that configure this sort of behaviour. I'm thinking of a YAML file maybe that configures this or something similar:

- prefix: my_company
   - skip_ci: yes
   - skip_github_badges: yes
   - skip_ignomes: yes
   - ...

Agreed, a more fine-grained logic / config for this would be nice. Could maybe have an argument to pass a YAML config file like this and go with interactive prompts otherwise. The config could also include other fields that we already have:

name: mypipeline
author: me
prefix: my_company
skip:
    - ci
    - github_badges
    - ignomes

Then the prompts could start with a simple y/n and then go more fine grained after that.. eg:

? Do you want to customise which parts of the template are used? [y/N] y

? Pipeline prefix: nf-core

? Skip GitHub CI workflows? [y/N] n

Note that this is a general idea, doesn't have to be a requirement for this specific PR necessarily. Could be taken in a subsequent PR.

I've added the functionality suggested in the comments here. So you can now either configure the pipeline creation with a yaml file by passing the filename to the --template-yaml flag, or by using interactive prompts. For example, passing

name: cool-pipe
author: me
prefix: cool-pipes-company
skip: 
    - ci
    - github_badges
    - igenomes
    - nf_core_configs

will create a pipeline called cool-pipe in the directory cool-pipes-company-cool-pipe with me as the author, and not copy the .github/workflow directory from the template, remove the igenomes.config, not include the github badges in the README.md and exclude nf_core/configs.

To allow the commands to run without prompts, I've also added a --plain flag which runs the command with the nf-core template silently.

This is just a first implementation, so it would be great with some feedback on how we want to customise the template further. In particular, I'm uncertain if we need to remove anything in the nextflow.config and nextflow_schema.json when skipping iGenomes, so it would be great with some input on that.

All features should be implemented now, and all tests are passing, so this PR should be ready to merge soon! It would be great though if people could try it out, to see if I've missed any nf-core branding or if anything seems to be broken

Forgot to mention this earlier, I've added an extra option for excluding nf-core/configs - I'll add it to the example in the comment above.

Nice! I'll give it another try tomorrow when I'm in the office.

Hi!
Awesome feature, really removes a lot of friction wrt adopting nf-core standard.
I tried the template generation and I've got some remarks:

• file references in .nf-core.yml still use the nf-core prefix
• I think the awstest and awsfulltest.yml gh workflow should be removed, as that's only applicable to real nf-core workflow and relies on tower
• I'm not sure nf-core lint will ever work, since it checks for the nf-core prefix.

Also, It'd be cool if the png generation could be edited to include the new prefix, but I think that's something to take up with the website team

I'm not sure nf-core lint will ever work, since it checks for the nf-core prefix.

I believe this is also stated in the current docs (predating this feature). I've never used linting in the pipelines I modified for this reason.

On this topic, I'd argue that if it is fixable, it might be better to have that in a separate PR (this one is quite large already)?

Of course, I totally agree! But I would argue to also remove that part from the CI tests then. I think the goal here is to provide a minimal amount of friction to boost the standard adoption.
Since the CI tests are big plus for the template, I'd like to have an option of "just works" minimal CI.

All of this can be handled in subsequent PR's of course. For now, we can just skip the CI during template generation.

I think that we should be careful not to confuse two separate issues here: identity of the pipeline and usage of nf-core/tools. I don't think that there's any need to rename .nf-core.yml because that's for tools - we also have a .prettier.yml file in the root too, for example.

Specific linting tests can disabled by this config so what I discussed with @ErikDanielsson was for these template flags to disable the relevant specific tests. Then the remainder of the linting should still run (and pass). No need to edit the linting code itself I think (or very much, anyway).

I think logo generation is out of scope - if it's not an nf-core pipeline there should be no branding, even with a different prefix. So just no image at all.

Agree on removing the awstest action workflows 👍🏻

Phil

I think that we should be careful not to confuse two separate issues here: identity of the pipeline and usage of nf-core/tools. I don't think that there's any need to rename .nf-core.yml because that's for tools - we also have a .prettier.yml file in the root too, for example.

What I meant is that .nf-core.yml contains nf-core naming.
e.g.

lint:
  files_exist:
    - CODE_OF_CONDUCT.md
    - assets/nf-core-preprocessing_logo_light.png
    - docs/images/nf-core-preprocessing_logo_light.png
    - docs/images/nf-core-preprocessing_logo_dark.png

Those fields are added to make linting pass -- the linting tests are named with an nf-core prefix. We could update the linting test to use the custom prefix as well, but since it does not make sense for nf-core create to create them for a non-nf-core pipeline I saw no reason to.

The AWS tests are now removed by default when run with a custom prefix. Linting should pass now also, no matter which sections of the template are skipped.

Awesome, thanks for the great work!

What I meant is that .nf-core.yml contains nf-core naming.

I'm a bit confused - yes that's intentional. Those lines in the YAML config are there to disable the lint tests that check for their presence.

Ah, it seems I misunderstood that part!