一个包含nf-core社区辅助工具的Python包。

在nf-core网站上阅读此文档： https://nf-co.re/tools

目录

• nf-core 工具安装

• nf-core 工具更新

• nf-core list - 列出可用管道

• nf-core launch - 使用交互式参数提示运行管道

• nf-core create-params-file - 创建参数文件

• nf-core download - 下载用于离线使用的管道

• nf-core licences - 列出管道中的软件许可

• nf-core create - 使用 nf-core 模板创建新的管道

• nf-core lint - 将管道代码与 nf-core 指南进行校验

• nf-core schema - 与管道模式文件协同工作

• nf-core bump-version - 更新 nf-core 管道版本号

• nf-core sync - 同步管道模板分支

• nf-core create-logo - 创建 nf-core 管道标志

• nf-core tui - 图形化探索 nf-core 命令行

• nf-core modules - 处理 DSL2 模块的相关命令

  • modules list - 列出可用的模块
    • modules list remote - 列出远程模块
    • modules list local - 列出已安装的模块
  • modules info - 显示有关模块的信息
  • modules install - 在管道中安装模块
  • modules update - 更新管道中的模块
  • modules remove - 从管道中删除模块
  • modules patch - 为模块创建补丁文件
  • modules create - 从模板创建模块
  • modules lint - 将模块与 nf-core 指南进行校验
  • modules test - 运行模块的测试
  • modules bump-versions - 提升模块的软件版本

• nf-core subworkflows - 处理子工作流程的命令

  • subworkflows list - 列出可用的子工作流程
    • subworkflows list remote - 列出远程子工作流程
    • subworkflows list local - 列出已安装的子工作流程
  • subworkflows info - 显示有关子工作流程的信息
  • subworkflows install - 在管道中安装子工作流程
  • subworkflows update - 更新管道中的子工作流程
  • subworkflows remove - 从管道中删除子工作流程
  • subworkflows create - 从模板创建子工作流程
  • subworkflows lint - 将子工作流程与 nf-core 指南进行校验
  • subworkflows test - 运行子工作流程的测试

• 引用

nf-core 工具包是用 Python 编写的，可以在其他包中导入和使用。有关内部 Python 函数的文档，请参阅 工具 Python API 文档。

安装

Bioconda

您可以从 bioconda 安装 nf-core/tools。

首先，安装 conda 并配置通道以使用 bioconda（参见 bioconda 文档）。然后，只需运行 conda 安装命令

conda install nf-core

或者，您也可以创建一个新环境，包含 nf-core/tools 和 nextflow

conda create --name nf-core python=3.12 nf-core nextflow
conda activate nf-core

Python 包索引

您还可以使用 pip 从 PyPI 安装 nf-core/tools，如下所示

pip install nf-core

Docker 镜像

有一个可以使用的 Docker 镜像，其中包含了所有要求（包括 Nextflow），因此应该可以直接使用。它被称为 nfcore/tools （注意：没有连字符！）

您可以在命令行中使用此容器，如下所示

docker run -itv `pwd`:`pwd` -w `pwd` -u $(id -u):$(id -g) nfcore/tools

• -i 和 -t 对于交互式 cli 提示的运行是必需的（这告诉 Docker 使用伪 tty 并附加 stdin）
• -v 参数告诉 Docker 将您的当前工作目录（pwd）绑定到容器中的相同路径，因此在那里创建的文件将保存到容器外部的本地文件系统中。
• -w 将容器中的工作目录设置为该路径，因此它与容器外的您的工作目录相同。
• -u 将您的本地用户帐户设置为容器内的用户，因此创建的任何文件都具有正确的所有权权限

在上述基本命令之后，您可以使用与其他类型安装相同的常规命令行标志。例如，要启动 viralrecon 管道

docker run -itv `pwd`:`pwd` -w `pwd` -u $(id -u):$(id -g) nfcore/tools launch viralrecon -r 1.1.0

如果您使用 $NXF_SINGULARITY_CACHEDIR 进行下载，还需要将此文件夹和环境变量提供给容器

docker run -itv `pwd`:`pwd` -w `pwd` -u $(id -u):$(id -g) -v $NXF_SINGULARITY_CACHEDIR:$NXF_SINGULARITY_CACHEDIR -e NXF_SINGULARITY_CACHEDIR nfcore/tools launch viralrecon -r 1.1.0

Docker bash 别名

上述基本命令至少有点难打。为了更容易使用，我们强烈建议将以下 bash 别名添加到您的 ~/.bashrc 文件中

alias nf-core="docker run -itv `pwd`:`pwd` -w `pwd` -u $(id -u):$(id -g) nfcore/tools"

一旦应用（您可能需要重新加载您的 shell），您就可以使用 nf-core 命令代替

nf-core list

Docker 版本

您可以使用 Docker 镜像标签来指定您想要使用的版本。例如，使用 nfcore/tools:dev 获取最新开发版本的代码，或使用 nfcore/tools:1.14 获取工具的 1.14 版本。如果您省略了它，它将默认为 :latest，这应该是最新稳定版本。

如果您需要在容器内部使用特定版本的 Nextflow，您可以自己构建镜像。在本地克隆存储库并检查您需要的 nf-core/tools 的任何版本。然后使用以下 --build-arg NXF_VER 标志构建

docker build -t nfcore/tools:dev . --build-arg NXF_VER=20.04.0

开发版本

如果您想要工具的最新开发版本，命令是

pip install --upgrade --force-reinstall git+https://github.com/nf-core/tools.git@dev

如果您打算编辑代码，首先在存储库中创建一个分支，然后将其克隆到本地。进入克隆的目录，并使用 pip 安装（也安装开发需求）

pip install --upgrade -r requirements-dev.txt -e .

使用特定的 Python 解释器

如果您愿意，您也可以使用特定的 Python 解释器运行工具。命令行使用和标志与使用 nf-core 命令时完全相同。请注意，模块是 nf_core，带下划线，而不是像控制台命令那样的连字符。

例如

python -m nf_core --help
python3 -m nf_core list
~/my_env/bin/python -m nf_core create --name mypipeline --description "This is a new skeleton pipeline"

与您自己的 Python 脚本一起使用

工具的功能是以这种方式编写的，您可以将其导入到自己的脚本中。例如，如果您想获取所有可用的 nf-core 管道的列表

import nf_core.list
wfs = nf_core.list.Workflows()
wfs.get_remote_workflows()
for wf in wfs.remote_workflows:
    print(wf.full_name)

请参阅 https://nf-co.re/tools/docs/ 获取功能文档。

自动版本检查

nf-core/tools 会自动检查网络以查看是否有新的 nf-core/tools 版本可用。如果您希望跳过此检查，请设置环境变量 NFCORE_NO_VERSION_CHECK。例如

export NFCORE_NO_VERSION_CHECK=1

更新工具

建议将 nf-core/tools 更新到最新版本。更新命令取决于安装它的系统，例如，如果您使用 conda 安装，可以使用

conda update nf-core

如果您使用 pip

pip install --upgrade nf-core

请参阅相应的文档以获取管理包的更多详细信息，例如 conda 或 pip。

激活 nf-core/tools 的 shell 完整性

nf-core 命令的自动完成在 bash、zsh 和 fish 中都可用。要激活它，请将以下行添加到相应的 shell 配置文件中。

在重启 shell 会话后，您应该有 nf-core 命令及其所有子命令和选项的自动完成。

[!注意] 添加的行将运行 nf-core 命令（这将也会减慢您的shell启动时间）。因此，您应该全局安装 nf-core/tools。您还可以使用 bash 和 zsh 中的 if type nf-core > /dev/null; then <YOUR EVAL CODE LINE> fi 或 fish 中的 if command -v nf-core &> /dev/null eval (env _NF_CORE_COMPLETE=fish_source nf-core) end 将其包裹起来。您需要然后在您的环境中源配置，以便激活补全。

[!提示] 如果您看到错误 command not found compdef，请确保您的配置文件在 eval 行之前包含行 autoload -Uz compinit && compinit。

列出管道

nf-core list 命令将显示所有可用的 nf-core 管道及其最新版本、发布时间和管道代码最近被拉取到本地系统的时间（如果有）。

命令输出的一个示例如下

要缩小列表，提供一个或多个额外关键词以根据标题、描述和主题中的匹配来过滤管道

您可以通过最新发布（-s release，默认值）、上次拉取本地副本的时间（-s pulled）、按字母顺序（-s name）或 GitHub 星标数量（-s stars）来对结果进行排序。

要将结果作为 JSON 输出用于后续使用，请使用 --json 标志。

默认情况下不返回存档管道。要包括它们，请使用 --show_archived 标志。

启动管道

一些 nextflow 管道有相当数量的命令行标志可以使用。为了帮助这一点，您可以使用 nf-core launch 命令。您可以选择基于网页的图形界面或交互式命令行向导工具来输入运行管道的参数。这两个界面都会在每个参数旁边显示文档并验证您的输入。

该工具使用管道的 nextflow_schema.json 文件来提供参数描述、默认值和分组。如果找不到管道的文件，将在运行时自动生成。

Nextflow params 变量保存在名为 nf-params.json 的 JSON 文件中，并由 nextflow 使用 -params-file 标志使用。这使得在将来重复使用它们变得更容易。

该命令接受一个参数 - 要自动拉取的 nf-core 管道的名称，或者包含 Nextflow 管道目录的路径（可以是任何管道，不必是 nf-core）。

完成后，向导将询问您是否要启动 Nextflow 运行。如果不是，您可以将带有 nf-params.json 输入文件的 Nextflow 命令复制和粘贴。

INFO     [✓] Input parameters look valid
INFO     Nextflow command:
         nextflow run nf-core/rnaseq -params-file "nf-params.json"


Do you want to run this command now?  [y/n]:

启动工具选项

• -r，--revision
  • 指定要运行的项目管道发布（或分支 / git 提交 sha）
• -i，--id
  • 您可以通过在网站上点击 "启动" 来使用 nf-core 管道的 Web GUI。填写完毕后，您将获得一个 ID，用于与该命令一起使用，该命令用于检索您的输入。
• -c，--command-only
  • 如果您不想在 JSON 文件中保存输入并使用 -params-file，则此选项将直接在 nextflow 命令中指定所有输入的参数。
• -p，--params-in PATH
  • 要使用之前管道运行中输入的值，您可以提供先前生成的 nf-params.json 文件。
  • 这将在向导启动之前覆盖管道模式默认值。
• -o，--params-out PATH
  • 保存参数 JSON 文件的路径。（默认：nf-params.json）
• -a，--save-all
  • 如果没有这个选项，管道将忽略所有与管道模式默认值匹配的值。
  • 此选项将找到的所有参数保存到JSON文件中。
• -h，--show-hidden
  • 管道JSON模式可以定义一些参数为“隐藏”，如果它们很少使用或者仅用于内部管道。
  • 此选项将强制向导显示所有参数，包括标记为“隐藏”的参数。
• --url
  • 更改用于图形界面的URL，这对于网站的开发工作很有用。

创建参数文件

有时手动编辑参数文件比使用nf-core launch提供的Web界面或交互式命令行向导更容易，例如在没有图形界面的远程服务器上运行具有许多选项的管道时。

您可以使用nf-core create-params-file命令创建包含管道所有参数的参数文件。然后可以将该文件传递给nextflow，使用-params-file标志。

此命令接受一个参数 - 要自动拉取的nf-core管道的名称，或者包含Nextflow管道的目录路径（可以是任何管道，不一定是nf-core）。

生成的YAML文件包含所有设置为管道默认值的参数，以及它们的注释中的描述。然后可以通过取消注释并修改您想传递给管道运行的参数的值来使用此模板。

默认情况下不包含隐藏选项，但可以使用-x/--show-hidden标志包含。

下载离线使用的管道

有时您可能需要在没有互联网连接的服务器或HPC系统上运行nf-core管道。在这种情况下，您需要首先获取管道文件，然后手动将它们传输到您的系统。

为了使此过程更容易并确保正确检索到正确版本的代码和软件容器，我们编写了一个下载辅助工具。

nf-core download命令将下载管道代码和机构nf-core/configs文件。它还可以选择性地下载所需的任何singularity镜像文件。

如果没有任何参数运行，下载工具将交互式提示您所需的信息。每个选项都有一个标志，如果提供了所有选项，则不需要用户输入即可运行。

下载完成后，您将看到以下类似文件结构

您可以通过简单地提供workflow文件夹的目录路径到您的nextflow run命令来运行管道

nextflow run /path/to/download/nf-core-rnaseq-dev/workflow/ --input mydata.csv --outdir results  # usual parameters here

[!NOTE] 如果您下载了Singularity容器镜像，您需要使用-profile singularity或者在您的配置文件中启用它。

下载的nf-core配置

管道文件将自动更新（将params.custom_config_base设置为../configs），以便在运行管道时可用本地机构配置。因此，如果nf-core/configs中可用，则使用-profile <NAME>应该可以正常工作。

[!WARNING] 当下载用于与Seqera平台一起使用的管道时，此选项不可用，因为应用程序会单独管理所有配置。

下载Apptainer容器

如果您使用Apptainer（Singularity），则nf-core download命令还可以为您获取所需的容器镜像。为此，在提示中选择singularity或在命令中指定--container-system singularity。然后，您的存档/目标输出目录还将包含一个单独的文件夹singularity-containers。

下载的工作流文件将再次编辑，在管道的nextflow.config文件末尾添加以下行

singularity.cacheDir = "${projectDir}/../singularity-images/"

这告诉Nextflow使用相对于工作流程的singularity-containers目录作为singularity镜像缓存目录。所有镜像都应该下载到那里，这样Nextflow将使用它们而不是从互联网上拉取。

Singularity缓存目录

我们强烈建议在您的系统上设置$NXF_SINGULARITY_CACHEDIR环境变量，即使它不是您将要运行Nextflow的系统。

如果找到，工具将首先将Singularity镜像获取到此目录，然后再复制到目标输出存档/目录。之前获取的任何镜像都将在此处找到并直接复制 - 这包括可能与其他管道或先前管道版本下载或下载尝试共享的镜像。

如果您在将运行管道的同一系统上运行下载（例如，一个共享文件系统，其中Nextflow将在以后日期没有互联网连接），您可以选择通过提示或cli选项--container-cache-utilisation amend仅使用缓存。这将指示nf-core download将所有Singularity镜像获取到$NXF_SINGULARITY_CACHEDIR目录，但不会将它们复制到工作流程存档/目录。工作流程配置文件不会被编辑。这意味着当您稍后运行工作流程时，Nextflow将直接使用缓存文件夹。

如果您正在下载不同系统的工作流程，您可以向nf-core download提供其图像缓存的内容信息。为了避免不必要的容器镜像下载，请选择--container-cache-utilisation remote，并将现有镜像列表作为纯文本文件提供到--container-cache-index my_list_of_remotely_available_images.txt。要在远程系统上生成此列表，请运行find $NXF_SINGULARITY_CACHEDIR -name "*.img" > my_list_of_remotely_available_images.txt。然后，工具将仅下载和复制到远程系统上缺失的镜像到您的输出目录。

Singularity镜像下载的工作方式

Singularity镜像下载使用两种方法来查找容器

1. 它运行下载的工作流程上的nextflow config以查找整个管道的process.container语句。这是用于DSL1管道的典型方法。
2. 它抓取工作流程modules目录中发现的任何具有.nf文件扩展名的文件，查找看起来像container = "xxx"的行。这是用于每个过程一个容器的DSL2管道的典型方法。

一些DSL2模块具有docker的容器地址（例如biocontainers/fastqc:0.11.9--0）以及用于直接下载Singularity容器的URL（例如https://depot.galaxyproject.org/singularity/fastqc:0.11.9--0）。如果两者都存在，则优先使用下载URL。

找到完整的容器列表后，将按以下顺序处理它们

1. 如果目标镜像已经存在，则不执行任何操作（例如，指定了$NXF_SINGULARITY_CACHEDIR和--container-cache-utilisation amend）
2. 如果在$NXF_SINGULARITY_CACHEDIR中找到，并指定了--container-cache-utilisation copy，则将它们复制到输出目录
3. 如果它们以http开头，它们将在Python内部直接下载（默认一次下载4个，您可以使用--parallel-downloads来自定义此操作）
4. 如果它们看起来像Docker镜像名称，它们将使用singularity pull命令获取。通过提供一个或多个--container-library参数选择查询的容器库（注册表）。例如，如果您使用带有-l quay.io -l ghcr.io -l docker.io的nf-core download调用，则每个镜像都将从quay.io拉取，除非遇到错误。随后，将查询ghcr.io和然后是docker.io以获取之前失败的任何镜像。
   • 这需要在系统上安装Singularity/Apptainer，并且速度会慢得多

请注意，压缩多个GB的二进制文件可能会很慢，因此在将Singularity镜像复制到输出目录时，建议指定--compress none。

如果下载速度远低于您的互联网连接速度，可以将--parallel-downloads设置为一个大数，以一次性下载大量镜像。

将下载适配到Seqera平台

Seqera平台（以前称为“Nextflow Tower”）提供了一个图形用户界面来监控管道运行、收集统计数据和配置计算资源。虽然添加到Seqera平台的管道最好托管在Git服务上，但对于网络访问受限的场所，也可以以断开连接、自给自足的仓库形式提供。选择--platform标志将下载适当的管道形式。

随后，可以将*.git文件夹移动到其最终位置，并使用file:/前缀将其与Seqera平台中的管道链接。

[!TIP] 即使没有访问Seqera平台，也可以使用--platform标志下载的管道，如果指定了绝对路径：nextflow run -r 2.5 file:/path/to/pipelinedownload.git。这种格式的下载允许您在一个文件中包含管道的多个版本，但需要始终明确指定修订版（例如-r 2.5）。

设施和为他人设置管道的人员可能会发现--tag参数很有用。它允许使用额外的标签自定义下载的管道，这些标签可用于在Seqera平台界面中选择特定的修订版。例如，一个认可的设施可以根据其结构化发布管理流程选择特定的修订版进行标记：--tag "3.12.0=testing" --tag "3.9.0=validated"，以便其员工可以轻松确保在生产中运行正确的管道版本。--tag参数后面必须跟一个key=value格式的字符串，可以提供多次。关键字必须引用有效的分支、标签或提交SHA。右侧必须符合Git标签的命名约定，并且可能还不存在于仓库中。

管道软件许可

有时查看管道中使用的工具的软件许可很有用。您可以使用licences子命令从每个conda / PyPI包中检索并打印nf-core管道中使用的软件许可。

[!WARNING] 此命令目前不适用于较新的DSL2管道。希望这将在不久的将来得到解决 。

创建新的管道

create子命令使用nf-core基础模板创建新的管道。给定管道名称、描述和作者后，它创建一个启动管道，该管道遵循nf-core最佳实践。

创建文件后，该命令将文件夹初始化为Git仓库并创建一个初始提交。这个“vanilla”提交（与模板工具的输出相同）非常重要，因为它允许我们将来将您的管道与基本模板保持同步。有关更多信息，请参阅nf-core同步文档。

运行该命令后，在GitHub下您的用户名处创建一个新的空仓库（不是nf-core组织），然后使用上面日志中的示例命令将计算机上的提交推送到该仓库。然后您可以在构建管道的过程中正常编辑、提交和推送。

请参阅nf-core文档，了解如何创建新的nf-core工作流程的完整教程。

[!提示] 如日志输出所示，请尽早来讨论您的管道想法！请参阅文档以获取说明。

请注意，如果未提供 nf-core create 所需的参数，它将交互式提示您输入。如果您愿意，也可以作为命令行参数提供。有关更多信息，请参阅 nf-core create --help。

自定义创建管道

nf-core create 命令提供了一些选项，允许您在打算不作为 nf-core 管道发布的情况下自定义管道创建。这可以通过两种方式完成：使用交互式提示，或使用 --template-yaml <file> 选项提供 template.yml 文件。这两种选项都允许您指定一个自定义管道前缀，而不是使用常见的 nf-core，以及在创建管道期间排除模板的部分。交互式提示将引导您完成管道创建过程。以下是一个 template.yml 文件的示例。

name: coolpipe
description: A cool pipeline
author: me
prefix: myorg
skip:
  - github
  - ci
  - github_badges
  - igenomes
  - nf_core_configs

这将创建一个名为 coolpipe 的管道，位于 myorg-coolpipe 目录中（<prefix>-<name>），作者为 me。它将排除所有可能的模板部分

• github：移除了用于 GitHub 托管管道所需的所有文件。具体来说，是 .github 文件夹和 .gitignore 文件。
• ci：从管道中移除了 GitHub 持续集成测试。具体来说，是 .github/workflows/ 文件夹。
• github_badges：从 README.md 文件中移除了 GitHub 徽章。
• igenomes：移除了与 iGenomes 相关的管道选项。包括 conf/igenomes.config 文件及其所有引用。
• nf_core_configs：排除 nf_core/configs 存储库选项，这为各种机构集群提供了多个配置配置文件。

要使用 nf-core 模板静默（即没有任何提示）运行管道创建，您可以使用 --plain 选项。

检查工作流程

lint 子命令检查给定的管道是否符合所有 nf-core 社区指南。这与自动化持续集成测试中使用的测试相同。

例如，当前版本看起来像这样

您可以使用 -k / --key 标志仅运行命名的测试以进行更快的调试，例如：nf-core lint -k files_exist -k files_unchanged。默认情况下，nf-core lint 命令会检查当前工作目录，要指定另一个目录，请使用 --dir <directory>。

检查文档

左侧的每个测试结果名称都是一个终端超链接。在大多数终端中，您可以通过 ctrl + click（ cmd + click）这些链接在浏览器中打开特定于此测试的文档。

或者访问 https://nf-co.re/tools/docs/latest/pipeline_lint_tests/index.html 并找到您的测试以了解更多信息。

检查配置

有时您可能希望禁用某些检查测试，尤其是如果您使用 nf-core/tools 与您的管道（该管道不在 nf-core 内）一起使用。

为了帮助您做到这一点，您可以在管道根目录中添加一个名为 .nf-core.yml 的工具配置文件（之前：.nf-core-lint.yml）。在这里，您可以列出您想要禁用的任何测试的名称并将它们设置为 False，例如

lint:
  actions_awsfulltest: False
  pipeline_todos: False

某些检查测试允许更大的粒度，例如仅跳过特定文件的测试。这在特定测试的文档中有记录，但通常涉及传递一个列表，例如

lint:
  files_exist:
    - CODE_OF_CONDUCT.md
  files_unchanged:
    - assets/email_template.html
    - CODE_OF_CONDUCT.md

请注意，您必须在 .nf-core.yml 文件中的 lint: 字段下列出 nf-core lint 命令的所有配置，因为此文件也用于其他命令的配置。

自动修复错误

一些代码检查工具可以尝试自动修复它们发现的任何问题。要启用此功能，请使用--fix标志。为了使此功能正常工作，管道必须是git仓库，且没有任何未提交的更改。这样，任何自动更改都可以进行审查和撤销（使用git checkout .），如果你不同意的话。

代码检查结果输出

nf-core lint的输出设计为在命令行上查看，并且故意简洁。你可以使用--show-passed查看所有通过测试，或使用--json和--markdown标志生成JSON / markdown结果。

管道模式

nf-core管道在其根目录中有一个nextflow_schema.json文件，该文件描述了工作流程使用的不同参数。这些文件允许在运行管道时自动验证输入，用于生成命令行帮助，并可用来构建启动管道的接口。管道模式文件根据JSONSchema规范（草案7）构建。

为了帮助与管道模式一起工作的开发者，nf-core工具有三个schema子命令

• nf-core schema validate
• nf-core schema build
• nf-core schema docs
• nf-core schema lint

验证管道参数

Nextflow可以在使用-params-file选项运行管道时，从JSON或YAML文件中获取输入参数。此命令将此类文件与管道模式进行验证。

用法为nf-core schema validate <pipeline> <parameter file>。例如，使用上面下载的管道，你可以运行

pipeline选项可以是包含管道的目录、模式文件的路径或nf-core管道的名称（将使用nextflow pull下载）。

构建管道模式

手动构建JSONSchema文档不是一件简单的事情，且容易出错。相反，nf-core schema build命令收集你的管道参数，并对你可能缺少或意外的参数进行交互式提示。如果找不到现有的模式，它将为你创建一个。

一旦构建完成，该工具可以将模式发送到nf-core网站，这样你就可以使用图形界面来组织和填写模式。工具会检查网站上的模式状态，并在完成后，在本地保存你的更改。

用法为nf-core schema build -d <pipeline_directory>，例如

你可以使用以下四个标志与此命令一起使用

• --dir <pipeline_dir>：指定一个除当前工作目录之外的管道目录
• --no-prompts：不进行确认提示即可进行更改。不会启动网络工具。
• --web-only：跳过将模式与管道参数进行比较，仅启动网络工具。
• --url <web_address>：提供在线工具的自定义URL。当本地测试时很有用。

显示管道模式的文档

要了解当前管道模式，你可以使用nf-core schema docs <pipeline-schema>显示nextflow_schema.json的内容。这将打印你的模式内容，格式为Markdown，到标准输出。

你可以使用以下四个标志与此命令一起使用

• --output <filename>：输出文件名。默认为标准输出。
• --format [markdown|html]：输出文档的格式。
• --force：覆盖现有文件
• --columns <columns_list>：包含在参数表中的CSV列列表

向管道模式添加新参数

如果你要向模式添加参数，你首先必须使用params范围将参数及其默认值添加到nextflow.config文件中。之后，运行nf-core schema build命令将参数添加到你的模式中，并打开图形界面以便轻松修改模式。

图形界面按组组织，组内存储单个参数。为了获得更好的概览，您可以使用“折叠组”按钮折叠所有组，然后新的参数将作为页面底部的唯一剩余项。现在，您可以使用“添加组”按钮创建新的组，或者将参数拖放到现有的组中。为此，必须展开组。如果您使用--help标志运行管道，将显示组标题，其描述将出现在管道参数页上。

现在您可以开始更改参数本身。新参数的ID应定义为不带空格的小写字母。描述是对参数的简短自由文本解释，如果您使用--help标志运行管道，它将出现。通过点击字典图标，您可以为管道参数页添加更长的解释。通常，它们包含有关参数设置或使用的数据源（如数据库或参考文献）的小段落。如果您想为参数指定一些条件，例如文件扩展名，您可以使用坚果图标打开设置。此菜单取决于您分配给参数的type。对于整数，您可以定义最小值和最大值，而对于字符串，可以指定文件扩展名。

type字段是您的管道模式中最重要的一点，因为它定义了您的输入数据类型以及如何解释它。这允许在启动管道之前进行广泛的测试。

管道模式的基本数据类型有

• 字符串
• 数字
• 整数
• 布尔值

对于string类型，您在设置（坚果图标）中有三个不同的选项：枚举值、模式和格式。第一个选项枚举值允许您指定一组特定的输入值。该列表必须用管道分隔。模式和格式设置可以相互依赖。格式必须是目录或文件路径。根据选择的格式设置，指定模式设置可能是最有效且节省时间的选项，尤其是对于文件路径。number和integer类型具有相同的设置。类似于string，有一个枚举值选项，可以指定min和max值。对于boolean，没有其他设置，默认值通常是false。通过添加标志到命令，可以将boolean值切换到true。此参数类型通常用于跳过管道的特定部分。

填写模式后，点击右上角的完成按钮，这将自动更新您的nextflow_schema.json。如果不起作用，可以从图形界面复制模式并将其粘贴到您的nextflow_schema.json文件中。

更新现有管道模式

首先更改nextflow.config文件中参数的默认值，然后更改管道模式很重要，因为配置文件中的值会覆盖管道模式中的值。要更改任何其他参数，请使用nf-core schema build --web-only以打开图形界面而无需重新构建管道模式。现在，可以像上面提到的那样更改参数，但请注意，更改参数数据类型取决于在nextflow.config文件中指定的默认值。

检查管道模式

管道模式是作为主要管道nf-core lint命令的一部分进行检查的，然而，有时快速检查JSONSchema的语法而不运行完整的检查运行可能很有用。

使用方法为 nf-core schema lint <schema>（默认为 nextflow_schema.json），例如

增加管道版本号

当发布nf-core管道的新版本时，需要在几个不同的地方更新版本号。辅助命令 nf-core bump-version 可自动执行此操作，以避免手动错误（以及挫折！）

该命令使用代码检查过程的结果，因此仅适用于通过这些测试的工作流程。

使用方法为 nf-core bump-version <new_version>，例如

您可以通过指定 --dir <pipeline_dir> 从当前工作目录更改目录。要更改所需的Nextflow版本而不是管道版本号，请使用 --nextflow 标志。

同步管道与模板

随着时间的推移，主要的nf-core管道模板会更新。为了保持所有nf-core管道的更新，当发布新的nf-core/tools版本时，我们将自动同步这些更新。这是通过维护一个特殊的 TEMPLATE 分支来完成的，其中包含一个纯净的nf-core模板副本，只包含第一次运行时使用的变量（名称、描述等）。此分支会更新，并且可以通过只包含主模板代码的更新来创建拉取请求。

请注意，每次发布nf-core/tools时都会自动进行管道同步，为每个管道创建一个自动的拉取请求。因此，您通常不需要亲自运行此命令！

此命令接受一个管道目录并尝试运行此同步。使用方法为 nf-core sync，例如

同步命令尝试从 origin 远程或现有的本地分支 TEMPLATE 中检出 TEMPLATE 分支。如果无法执行这两者中的任何一个，则将失败。在您第一次启动管道时，nf-core create 命令应自动创建此模板。如果您遇到困难，请参阅nf-core网站同步文档。

要同步当前工作目录以外的目录，请使用 --dir <pipline_dir>。

默认情况下，工具将收集管道目录当前分支中的工作流程变量。您可以使用 --from-branch 标志指定不同的分支。

最后，如果您提供 --pull-request 标志，则命令将推送任何更改到远程，并尝试使用GitHub API创建拉取请求。GitHub用户名和存储库名称将从远程URL获取（请参阅 git remote -v | grep origin），或可以与 --username 和 --github-repository 一起提供。

要创建拉取请求，需要API身份验证的个人访问令牌。这些可以在https://github.com/settings/tokens 创建。请使用 --auth-token 标志提供。

创建nf-core管道徽标

nf-core create-logo 命令根据nf-core模板和管道名称创建徽标。您可以使用 --width 标志指定徽标的像素宽度。此外，您可以使用 --format 标志指定输出格式为 png 或 svg。默认格式为 png。

使用方法为 nf-core create-logo <text>，例如

工具CLI TUI

CLI: 命令行界面 TUI: 终端用户界面

nf-core 命令行界面相当庞大，有许多命令和选项。为了使其更容易探索和使用，请运行 nf-core tui 以启动图形终端界面。

此功能使用 Textualize/trogon 实现，并基于使用 Click 的底层CLI实现。

模块

随着Nextflow DSL2的出现，我们正在创建一个模块的集中式仓库。这些是软件工具流程定义，可以被导入到任何管道中。这允许多个管道使用相同的代码来共享工具，并提供了更高的粒度和单元测试程度。

nf-core DSL2模块仓库位于https://github.com/nf-core/modules

自定义远程模块

模块超级命令包含两个标志来指定自定义远程

• --git-remote <git远程url>：指定应该从哪个git URL获取模块的仓库。默认为nf-core/modules的github仓库。
• --branch <分支名称>：指定应该从哪个分支获取模块。默认为您的仓库的默认分支。

例如，如果您想从位于gitlab.com的nf-core/modules-test仓库安装fastqc模块，可以使用以下命令

nf-core modules --git-remote git@gitlab.com:nf-core/modules-test.git install fastqc

请注意，自定义远程必须遵循与nf-core/modules类似的目录结构，以便nf-core modules命令能正常工作。

模块安装的目录将通过提示或从.nf-core.yml文件中的org_path获取（如果可用）。如果您的模块位于modules/my-folder/TOOL/SUBTOOL，您的.nf-core.yml应该有

org_path: my-folder

请避免从两个不同的远程安装相同的工具，因为这可能导致进一步错误。

模块命令在初始化期间将尝试从远程仓库拉取更改。如果您想禁用此操作，例如出于性能原因或如果您想离线运行命令，可以使用--no-pull标志。但是请注意，命令仍需要克隆之前未使用过的仓库。

私有远程仓库

您可以使用模块命令与私有远程仓库。确保您的本地git已正确配置为您的私有远程，然后以与公共远程仓库相同的方式指定远程。

列出模块

nf-core modules list命令提供了remote和local子命令，用于列出远程仓库和本地管道中安装的模块。这两个子命令都允许使用模式来通过关键字过滤模块，例如：nf-core modules list <子命令> <关键字>。

列出远程模块

要列出nf-core/modules上可用的所有模块，可以使用nf-core modules list remote，这将打印所有可用的模块到终端。

列出已安装的模块

要列出本地管道目录中安装的模块，可以使用nf-core modules list local。这将默认列出当前工作目录中安装的模块。如果您想指定其他目录，请使用--dir <pipeline_dir>标志。

显示有关模块的信息

要快速了解模块的工作原理，请使用nf-core modules info <工具>。这将显示命令行上的模块文档，类似于在nf-core网站上可用的文档。

在管道中安装模块

您可以使用nf-core modules install在您的管道中从nf-core/modules安装模块。以这种方式安装的模块将被安装到./modules/nf-core/modules目录。

您可以将模块名称作为可选参数传递给nf-core modules install，而不是使用CLI提示，例如：nf-core modules install fastqc。您可以通过使用--dir <pipeline_dir>指定除当前工作目录之外的管道目录。

在安装模块时，您可以使用以下三个附加标志

• --force：覆盖之前安装的模块版本。
• --prompt：使用CLI提示选择模块版本。
• --sha <commit_sha>：在特定提交处安装模块。

更新管道中的模块

您可以使用 nf-core modules update 命令更新您管道中从远程仓库安装的模块。

您可以将模块名称作为可选参数传递给 nf-core modules update 命令，而不是使用命令行提示符，例如：nf-core modules update fastqc。您可以使用 --dir <pipeline dir> 指定除了当前工作目录以外的管道目录。

您还可以使用此命令的五个附加标志

• --force：即使模块看起来是最新的也要重新安装模块
• --prompt：使用CLI提示选择模块版本。
• --sha <commit_sha>：从 nf-core/modules 仓库安装模块到特定提交。
• --preview/--no-preview：在安装之前显示已安装文件与新版本之间的差异。
• --save-diff <filename>：将差异保存到文件而不是就地更新。然后可以使用 git apply <filename> 应用差异。
• --all：使用此标志在管道中的所有模块上运行命令。

如果您不想更新某些模块或想要将它们更新到特定版本，则可以使用 .nf-core.yml 配置文件。例如，您可以在 .nf-core.yml 文件中添加以下内容以防止从 nf-core/modules 安装的 star/align 模块被更新

update:
  https://github.com/nf-core/modules.git:
    nf-core:
      star/align: False

如果您希望此模块只更新到特定版本（或降级），则可以指定版本

update:
  https://github.com/nf-core/modules.git:
    nf-core:
      star/align: "e937c7950af70930d1f34bb961403d9d2aa81c7"

此方法也适用于仓库级别。例如，如果您想排除所有从 nf-core/modules 安装的模块更新，则可以添加

update:
  https://github.com/nf-core/modules.git:
    nf-core: False

或者，如果您想将 nf-core/modules 中的所有模块更新到特定版本

update:
  https://github.com/nf-core/modules.git:
    nf-core: "e937c7950af70930d1f34bb961403d9d2aa81c7"

请注意，在 .nf-core.yml 文件中指定的模块版本比使用命令行标志指定的版本具有更高的优先级，这有助于您编写可重复的管道。

从管道中删除模块

要从您的管道中删除模块，请运行 nf-core modules remove。

您可以将模块名称作为可选参数传递给 nf-core modules remove 命令，而不是使用命令行提示符，例如：nf-core modules remove fastqc。要指定管道目录，请使用 --dir <pipeline_dir>。

为模块创建补丁文件

如果您想对本地安装的模块进行少量更改，同时仍然保持与远程版本的同步，则可以使用 nf-core modules patch 创建补丁文件。

生成的补丁与 nf-core modules update 一起工作：当您安装模块的新版本时，该命令会尝试自动应用补丁。如果新版本的模块修改了补丁相同的行，则补丁应用失败。在这种情况下，将安装新版本，但保留旧的补丁文件。

在检查补丁模块时，检查命令将检查补丁的有效性。在运行其他检查测试时，将反向应用补丁，并检查原始文件。

创建新模块

此命令从 nf-core 模块模板创建新的 nf-core 模块。这确保了您的模块遵循 nf-core 指南。模板包含大量的 TODO 消息，以引导您完成对模板所需进行的更改。

您可以使用 nf-core modules create 创建新模块。

此命令既可用于为共享的 nf-core/modules 仓库编写模块，也可用于创建管道的本地模块。

您正在工作的存储库类型通过根目录下的.nf-core.yml文件中的repository_type标志检测，设置为pipeline或modules。命令将自动搜索父目录以设置根路径，因此您可以在子目录中运行命令。它将从当前工作目录开始，或者使用--dir <directory>指定的目录。

nf-core modules create命令将提示您相关的问题，以便创建所有必要的模块文件。

检查模块是否符合nf-core规范

运行nf-core modules lint命令，检查当前工作目录（管道或nf-core/modules克隆）中的模块是否符合nf-core规范。

使用--all标志运行所有找到的模块的lint检查。使用--dir <pipeline_dir>指定除当前工作目录以外的目录。

为模块创建测试

nf-core/modules上的所有模块都必须使用最小测试数据对单元测试有严格的要求。我们使用nf-test作为我们的测试框架。每个模块都附带了一个在test/main.nf.test中的测试文件模板。将文件中的占位符代码替换为您特定的输入、输出和过程。为了在编写测试后生成相应的快照，您可以使用nf-core modules test命令。此命令将运行nf-test test两次，以检查快照的稳定性，即多次运行生成相同的快照。

您可以在命令中指定模块名，格式为TOOL/SUBTOOL，或者稍后通过交互式提示提供。

如果您更改了测试内容并希望更新快照，请运行

nf-core modules test --update

如果您只想运行一次测试而不检查快照的稳定性，可以使用--once标志。

提高模块中的bioconda和容器版本

如果您正在为nf-core/modules存储库做出贡献并希望提高某些模块的bioconda和容器版本，可以使用nf-core modules bump-versions辅助工具。这将提高单个或所有模块的bioconda版本到最新版本，并获取正确的Docker和Singularity容器标签。

如果您不希望更新某些模块或希望将它们更新到特定版本，可以使用.nf-core.yml配置文件。例如，您可以在.nf-core.yml文件中添加以下内容以防止更新star/align模块

bump-versions:
  star/align: False

如果您希望此模块只更新到特定版本（或降级），则可以指定版本

bump-versions:
  star/align: "2.6.1d"

子工作流程

在nf-core modules发布后，我们现在还可以提供nf-core子工作流程，以充分利用DSL2模块化的力量。子工作流程是多个模块定义的链，可以导入到任何管道中。这允许多个管道使用相同的代码执行相同的任务，并提供更高的重用性和单元测试程度。

为了使我们能够测试模块和子工作流程，我们将nf-core DSL2子工作流程放入模块存储库的subworkflows目录，地址为https://github.com/nf-core/modules。

自定义远程子工作流程

nf-core/tools版本2.7中发布的子工作流程超命令包含两个标志用于指定自定义远程存储库

• --git-remote <git remote url>：指定从哪个存储库获取子工作流程，作为git URL。默认为nf-core/modules的github存储库。
• --branch <branch name>：指定从哪个分支获取子工作流程。默认为您的存储库的默认分支。

例如，如果您想从位于gitlab.com的存储库nf-core/modules-test的subworkflows分支安装bam_stats_samtools子工作流程，您可以使用以下命令

nf-core subworkflows --git-remote git@gitlab.com:nf-core/modules-test.git --branch subworkflows install bam_stats_samtools

请注意，自定义远程必须遵循与 nf-core/modules 类似的目录结构，以便 nf-core subworkflows 命令能够正常工作。

子工作流安装的目录将通过提示或从 .nf-core.yml 文件中的 org_path 获取（如果可用）。如果你的子工作流位于 subworkflows/my-folder/SUBWORKFLOW_NAME，你的 .nf-core.yml 文件应包含以下内容：

org_path: my-folder

请避免从两个不同的远程安装相同的工具，因为这可能导致进一步错误。

子工作流命令在初始化过程中将尝试从远程存储库中拉取更改。如果你想禁用此功能，例如由于性能原因或你想离线运行命令，可以使用标志 --no-pull。但请注意，命令仍需要克隆之前未使用过的存储库。

私有远程仓库

你可以使用具有私有远程存储库的子工作流命令。确保你的本地 git 已正确配置为你的私有远程，然后以与公共远程存储库相同的方式指定远程。

列出子工作流

nf-core subworkflows list 命令提供了 remote 和 local 子命令，分别用于列出远程存储库中安装的子工作流和本地管道中的子工作流。这两个子命令都允许使用模式通过关键词过滤子工作流，例如：nf-core subworkflows list <subworkflow_name> <keyword>。

列出远程子工作流

要列出 nf-core/modules 上可用的所有子工作流，可以使用 nf-core subworkflows list remote，它将在终端打印出所有可用的子工作流。

列出已安装的子工作流

要列出本地管道目录中安装的子工作流，可以使用 nf-core subworkflows list local。默认情况下，这将列出当前工作目录中安装的子工作流。如果你想指定其他目录，请使用 --dir <pipeline_dir> 标志。

显示子工作流信息

要快速了解子工作流的工作方式，请使用 nf-core subworkflows info <subworkflow_name>。这将显示子工作流的文档，类似于在 nf-core 网站 上可用的内容。

在管道中安装子工作流

你可以使用 nf-core subworkflows install 在你的管道中从 nf-core/modules 安装子工作流。以这种方式安装的子工作流将安装到 ./subworkflows/nf-core 目录。

你可以像上面那样将子工作流名称作为可选参数传递给 nf-core subworkflows install，或者仅运行 nf-core subworkflows install 从可用子工作流列表中选择。

在安装子工作流时，你可以使用以下四个附加标志

• --dir：管道目录，默认为当前工作目录。
• --force：覆盖先前安装的子工作流版本。
• --prompt：使用 cli 提示选择子工作流版本。
• --sha <commit_sha>：在特定的提交处安装子工作流。

更新管道中的子工作流

你可以使用 nf-core subworkflows update 在你的管道中更新从远程存储库安装的子工作流。

你可以像上面那样将子工作流名称作为可选参数传递给 nf-core subworkflows update，或者仅运行 nf-core subworkflows update 从可用子工作流列表中选择。

你可以使用以下六个附加标志与该命令一起使用

• --dir：管道目录，默认为当前工作目录。
• --force：即使看起来已经是最新的，也要重新安装子工作流。
• --prompt：使用 cli 提示选择子工作流版本。
• --sha <commit_sha>：从 nf-core/modules 存储库在特定提交处安装子工作流。
• --preview/--no-preview：在安装之前显示已安装文件与新版本之间的差异。
• --save-diff <filename>：将差异保存到文件而不是就地更新。然后可以使用 git apply <filename> 应用差异。
• --all：使用此标志在管道中的所有子工作流上运行命令。
• --update-deps：使用此标志自动更新子工作流的所有依赖项。

如果您不想更新某些子工作流或希望将它们更新到特定版本，可以使用.nf-core.yml配置文件。例如，您可以通过在.nf-core.yml文件中添加以下内容来阻止从nf-core/modules安装的bam_rseqc子工作流被更新：

update:
  https://github.com/nf-core/modules.git:
    nf-core:
      bam_rseqc: False

如果您只想将此子工作流更新到特定版本（或降级），则可以指定该版本

update:
  https://github.com/nf-core/modules.git:
    nf-core:
      bam_rseqc: "36a77f7c6decf2d1fb9f639ae982bc148d6828aa"

这同样适用于仓库级别。例如，如果您想排除所有从nf-core/modules安装的模块和子工作流的更新，可以添加以下内容：

update:
  https://github.com/nf-core/modules.git:
    nf-core: False

或者，如果您想将nf-core/modules中的所有子工作流更新到特定版本

update:
  https://github.com/nf-core/modules.git:
    nf-core: "e937c7950af70930d1f34bb961403d9d2aa81c7"

请注意，在.nf-core.yml文件中指定的子工作流版本优先于通过命令行标志指定的版本，这有助于您编写可重复的管道。

从管道中删除子工作流

要从您的管道中删除子工作流，运行nf-core subworkflows remove。

您可以将子工作流名称作为可选参数传递给nf-core subworkflows remove，就像上面那样，或者通过只运行nf-core subworkflows remove从可用的子工作流列表中选择它。要指定管道目录，请使用--dir <pipeline_dir>。

创建新的子工作流

此命令从nf-core子工作流模板创建新的nf-core子工作流。这确保了您的子工作流遵循nf-core指南。模板包含大量的TODO消息，以指导您进行必要的模板更改。有关创建新子工作流的更多详细信息，包括命名规则和分步指南，请参阅子工作流文档。

您可以使用nf-core subworkflows create创建新的子工作流。

此命令既可以用于编写共享nf-core/modules仓库的子工作流，也可以用于为管道创建本地子工作流。

您正在工作的存储库类型通过根目录下的.nf-core.yml文件中的repository_type标志检测，设置为pipeline或modules。命令将自动搜索父目录以设置根路径，因此您可以在子目录中运行命令。它将从当前工作目录开始，或者使用--dir <directory>指定的目录。

nf-core subworkflows create命令将提示您相关的问题，以便创建所有必要的子工作流文件。

为子工作流创建测试

nf-core/modules上的所有子工作流都有使用最小测试数据进行单元测试的严格要求。我们使用nf-test作为我们的测试框架。每个子工作流都已经在test/main.nf.test中提供了测试文件的模板。用您特定的输入、输出和过程替换该文件中的占位符代码。为了在编写测试后生成相应的快照，您可以使用nf-core subworkflows test命令。此命令将运行nf-test test两次，以检查快照稳定性，即多次运行生成相同的快照。

您可以在命令中指定子工作流名称，或稍后通过交互式提示提供。

如果您更改了测试内容并希望更新快照，请运行

nf-core subworkflows test --update

如果您只想运行一次测试而不检查快照的稳定性，可以使用--once标志。

检查子工作流是否符合nf-core指南

运行nf-core subworkflows lint命令，检查当前工作目录（管道或nf-core/modules的克隆）中的子工作流是否符合nf-core指南。

使用--all标志对找到的所有子工作流进行linting。使用--dir <pipeline_dir>指定与当前工作目录不同的目录。

引用

如果您在您的工作中使用了nf-core tools，请按照以下方式引用nf-core出版物：

社区协作的生物信息学管道框架nf-core。

Philip Ewels, Alexander Peltzer, Sven Fillinger, Harshil Patel, Johannes Alneberg, Andreas Wilm, Maxime Ulysse Garcia, Paolo Di Tommaso & Sven Nahnsen。

Nat Biotechnol. 2020年2月13日。doi: 10.1038/s41587-020-0439-x。