Nextflow 容器与 Conda 依赖环境实战指南用 Docker、Singularity/Apptainer、Conda 与 Wave 构建可复现科学流程【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000 scientists worldwide. 165 ready-to-use validated skills plus 100 scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills本文以本仓库 Nextflow 技能中的软件依赖文档为主体系统讲解 Nextflow 如何在每个进程的隔离软件环境中管理依赖如何选择并启用 Docker、Singularity/Apptainer、Podman、Conda 与 Wave 等引擎如何编写container与conda指令以及如何规避多引擎冲突、宿主机文件不可见、HPC 拉取风暴等常见坑。读完本文你将掌握从本地笔记本到 HPC 集群再到云端让科学流程可复现、可移植的完整环境配置方案。为什么要为每个流程隔离软件环境Nextflow 的核心设计目标之一是可复现reproducible与可移植portable。因此它会把每一个process都运行在相互隔离的软件环境中绝不依赖宿主机上手工安装的工具。这样带来的直接收益是可复现同一流程在任何机器上运行使用的都是完全相同版本的镜像或环境发布结果时有据可查可移植流程代码写一次、随处运行——本地、HPCSLURM/SGE/LSF/PBS与云AWS Batch、Google Batch、Azure Batch、Kubernetes之间只切换配置与 profile而不改动流程逻辑可观测每个任务在独立的 work 目录中运行配合-resume缓存与固定版本号问题定位与增量重算都变得简单。这一点在仓库的 Nextflow 技能主文档 中被反复强调One container/conda env per process; never rely on tools installed on the host每个进程一个容器/Conda 环境绝不依赖宿主机工具。而本仓库的 containers.md 原文 则是在 Nextflow 官方容器、Conda 与 Wave 文档的基础上整理的实操型速查手册与 configuration.md配置、执行器、CLI和 running-pipelines.md运行流程、离线执行共同构成配置与扩展这一知识支线。选择引擎先决定运行环境再写流程Nextflow 支持多种容器引擎与包管理器它们在适用场景上差异明显。原文档给出了一张关键决策表这里完整保留并补充说明引擎适用场景启用方式Docker本地开发 / 笔记本 / 有 root 或 docker 组的 CIdocker.enabled trueSingularity / ApptainerHPC 集群无 root、共享文件系统——学术界最常见singularity.enabled true或apptainer.enabled truePodman无 root 的 Docker 替代方案podman.enabled trueCharliecloud / Sarus / Shifter站点特定的 HPC 运行时charliecloud.enabled true等Conda / Mamba没有容器运行时可用需要快速创建环境conda.enabled trueWave从 Conda 配方/Dockerfile 按需构建容器、私有镜像仓库、云端加速wave.enabled true核心铁律一次只启用一个容器引擎。同时打开两个引擎会导致报错或难以预料的行为。nf-core 流水线把各引擎封装成命名 profile用户通常只需在命令行传-profile docker、-profile singularity或-profile conda即可无需手改配置文件。以本仓库 configuration.md 中的 profile 写法为例一个典型的nextflow.config会这样组织profiles { standard { process.executor local } docker { docker.enabled true; docker.runOptions -u $(id -u):$(id -g) } singularity { singularity.enabled true; singularity.autoMounts true } conda { conda.enabled true } slurm { process.executor slurm process.queue compute } test { params.input ${baseDir}/assets/test_samplesheet.csv params.genome R64-1-1 } }运行时用逗号组合多个 profile且顺序敏感后者覆盖前者nextflow run main.nf -profile test,singularity注意容器/基础设施类 profiledocker、singularity、conda互斥只能选一个而test这类数据/profile 可以与引擎组合使用。仓库 SKILL.md 中的最佳实践也建议先跑通内置的testprofile 验证环境再进行真实数据运行。container 指令让每个进程声明自己的镜像引擎决定怎么运行而container指令决定跑什么。每个 process 都可以直接声明它所需的镜像process SAMTOOLS_SORT { container quay.io/biocontainers/samtools:1.19.2--h50ea8bc_0 conda bioconda::samtools1.19.2 // fallback when -profile conda is used script: samtools sort - $task.cpus -o sorted.bam $input }这里的关键是同时声明container和conda使用-profile docker/-profile singularity时走镜像使用-profile conda时走 Conda 环境同一模块在任意引擎下都能工作。nf-core 模块遵循同样的双声明约定但conda指令不是内联字符串而是引用一个独立的environment.yml文件。本仓库 developing.md 中给出了 nf-core 模块的标准写法conda ${moduleDir}/environment.yml // references the file above (NOT inline package strings) container ${ workflow.containerEngine in [singularity, apptainer] !task.ext.singularity_pull_docker_container ? https://depot.galaxyproject.org/singularity/samtools:1.19.2--h50ea8bc_0 : quay.io/biocontainers/samtools:1.19.2--h50ea8bc_0 }对应的environment.yml长这样来自 developing.mdname: samtools channels: - conda-forge - bioconda dependencies: - bioconda::samtools1.19.2值得注意的细节nf-core 模块的container表达式会根据当前引擎自动切换镜像来源——在 Singularity/Apptainer 下优先使用 Galaxy depot 的.sif兼容地址其余情况使用 Biocontainers 的quay.io/biocontainers/...镜像同时通过task.ext.singularity_pull_docker_container允许从 Docker 镜像自动转换。这些镜像都由 Bioconda 配方自动构建标签严格固定到版本号与构建哈希如1.19.2--h50ea8bc_0从而保证不同机器上拿到完全一致的工具。Docker本地开发与 CI 的首选在个人电脑、笔记本电脑或具备 root 权限或用户已加入 docker 组的 CI 上Docker 是最直接的选择。在nextflow.config中启用并设置运行选项docker { enabled true runOptions -u $(id -u):$(id -g) // avoid root-owned output files }runOptions中-u $(id -u):$(id -g)是高频实践默认情况下容器内以 root 运行落盘的输出文件会属于 root导致后续无法清理或读取。显式把当前用户与组 ID 传入即可避免产生 root 属主文件。Singularity / ApptainerHPC 集群的标配在 HPC 集群上用户通常没有 root 权限且各计算节点共享文件系统——这正是 Singularity/Apptainer 的主场也是学术界最常见的部署方式。基础配置如下singularity { enabled true autoMounts true // auto-bind host paths cacheDir /shared/singularity // or set NXF_SINGULARITY_CACHEDIR }几个关键点自动转换与缓存Nextflow 会在首次使用时把 Docker 镜像自动转换为 SIFSingularity Image Format并缓存。在集群上务必设置共享的cacheDir或环境变量NXF_SINGULARITY_CACHEDIR让所有计算节点复用同一次拉取否则每个任务各自下载会导致拉取风暴和配额爆炸。绑定额外路径如果autoMounts true未能自动绑定某些宿主机路径比如独立的/scratch挂载点用runOptions -B /scratch手动补充绑定。工作目录和输入文件所在路径必须处于已绑定的路径上否则 Singularity 任务会看不到输入文件。ApptainerApptainer 即更名后的 Singularity配置项完全一致只是作用域名称改为apptainerapptainer.enabled true。仓库 configuration.md 的环境变量一节也同时列出了NXF_SINGULARITY_CACHEDIR与NXF_APPTAINER_CACHEDIR。关于Singularity 看不到输入文件这一高发问题的排查原文档给出的建议是先确认autoMounts已开启或显式加-B绑定再确认 work 目录与输入文件都位于已绑定的路径集合之内。Conda / Mamba没有容器运行时时的退路当集群或环境完全没有容器运行时可用时Conda/Mamba 是兜底方案。配置如下conda { enabled true useMamba true // faster solver channels conda-forge,bioconda // priority order (this is the default since 26.04) cacheDir /shared/conda_envs } process.conda bioconda::bwa0.7.17 bioconda::samtools1.19要点说明useMamba true使用 Mamba 求解器环境解析速度显著快于默认 Conda 求解器channels按优先级顺序列出频道conda-forge,bioconda是 Nextflow 26.04 以来的默认顺序cacheDir或环境变量NXF_CONDA_CACHEDIR复用已构建的环境避免每个任务重复解析process.conda可以在全局层面为进程声明包依赖也可以在单个 process 内声明。务实的警告Conda 是所有选项中可复现性最差的一种——求解器版本漂移solver drift可能导致相同声明的依赖在不同时间解析出不同版本而且它没有操作系统级隔离。因此对于要发表的结果优先使用容器Conda 只适合没有容器运行时的应急场景。仓库 SKILL.md 也把conda定位为last resort最后手段。Wave Fusion按需构建与云存储加速Wave 与 Fusion 是面向现代云端/HPC 场景的一对组合Wave按需构建或增强容器——可以从conda指令或 Dockerfile 实时构建镜像并推送到镜像仓库还能挂载私有镜像仓库凭据免去手工docker build/push的环节Fusion一个虚拟分布式文件系统让任务像访问本地文件一样读写云对象存储S3/GCS在云执行器上能带来显著的 I/O 加速。wave { enabled true strategy conda // build images from process conda directives } fusion.enabled true // pair with Wave on cloud executors tower.accessToken secrets.TOWER_ACCESS_TOKEN // some Wave features use Seqera credsstrategy conda表示 Wave 直接从各进程的conda指令构建镜像fusion.enabled true通常与 Wave 搭配用于云执行器如 AWS Batch部分 Wave 功能需要 Seqera 平台凭据tower.accessToken。在 configuration.md 的云执行器章节中也明确把Wave Fusion 加速云端 I/O列为云部署的可选增强手段。常见坑与规避清单原文档以实战为导向总结了六大高频问题这里逐一展开同时启用两个引擎→ 会导致报错或难以预料的行为。正确做法是只启用一个引擎且尽量通过 profile 管理参考上文 profiles 示例与仓库 SKILL.md 中container/infra profiles are mutually exclusive的说明。Docker 产生 root 属主输出文件→ 在docker.runOptions中加入-u $(id -u):$(id -g)让容器进程以当前用户身份运行。Singularity 看不到输入文件→ 开启singularity.autoMounts true或通过runOptions -B /path显式绑定并确认 work 目录与输入文件都在已绑定的路径上。HPC 拉取风暴 / 配额爆炸→ 设置共享的NXF_SINGULARITY_CACHEDIR或cacheDir并在有网络的机器上先用nf-core pipelines download预拉取全部镜像详见 running-pipelines.md 的离线执行章节。版本未固定→ 始终使用完整带版本的镜像标签如samtools:1.19.2--h50ea8bc_0条件允许时进一步固定到 digest。使用latest会破坏可复现性——仓库 SKILL.md 明确要求发布科研结果前不要使用latest。离线环境→ 预先准备好全部镜像Singularity SIF 或本地 Docker registry并设置NXF_OFFLINEtrue禁用网络调用。与配置系统、CLI 与离线模式的联动容器配置不是孤立的它与 Nextflow 的配置体系、CLI 工具与运行模式深度耦合。以下几点是原文档之外、从仓库相关文档中可确认的高价值补充用nextflow inspect预检容器解析。无需真正运行流程即可查看每个进程最终解析到哪个容器镜像nextflow inspect pipeline该命令在 configuration.md 的 CLI 参考表中列出适合在提交到 HPC/云之前快速核对镜像地址与引擎选择是否正确。关键环境变量速查摘自 configuration.md变量作用NXF_VER固定本次运行的 Nextflow 引擎版本NXF_SINGULARITY_CACHEDIR/NXF_APPTAINER_CACHEDIRSIF 镜像缓存目录HPC 上务必设置共享目录NXF_CONDA_CACHEDIR缓存的 Conda 环境目录NXF_OFFLINEtrue完全禁用网络调用离线/内网运行NXF_SYNTAX_PARSERv2启用严格语法解析器26.04 起为默认NXF_HOME/NXF_WORK默认家目录 / 默认 work 目录离线air-gapped运行的标准流程。在联网机器上把流水线、配置与容器一起打包nf-core pipelines download nf-core/rnaseq \ --revision 3.14.0 \ --container-system singularity \ # pre-convert images to SIF --compress none \ --outdir nf-core-rnaseq转移到离线机器后export NXF_OFFLINEtrue export NXF_SINGULARITY_CACHEDIR/shared/sif nextflow run nf-core-rnaseq/3_14_0 -profile singularity --input ... --outdir results这条路径与预拉取镜像避免 HPC 拉取风暴是同一思路的两种落地方式完整细节见 running-pipelines.md。仓库内的配套验证。本仓库的 tests/skill-requirements.toml 中[skills.nextflow]一节声明了packages [nf-core]表明该技能在仓库内的验证环境依赖 nf-core 工具链这与运行层面的引擎选择自由度Docker/Singularity/Conda/Wave 任选其一互补——工具链负责开发与校验引擎负责运行时隔离。小结Nextflow 的软件依赖管理遵循一条清晰的主线用container/conda指令在进程级声明依赖用 profile 在运行级选择引擎用固定版本与共享缓存保证可复现与规模化。Docker 负责本地与 CISingularity/Apptainer 接管 HPCConda 作为无容器环境的退路Wave Fusion 面向云端按需构建与加速。只要遵守只启用一个引擎、固定镜像版本、共享缓存目录这三条原则就能让同一套科学流程在任意基础设施上稳定复现。延伸阅读containers.md 原文——本文主体引擎决策表与坑位清单速查SKILL.md——Nextflow 技能总览、安装要求Bash Java 17、运行与开发双模式configuration.md——nextflow.config、scopes、profiles、执行器、缓存与 CLI 全参考running-pipelines.md——样本表、参数文件、iGenomes、离线运行与故障排查developing.md——nf-core 模块的container/conda双声明规范与ext.args约定【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000 scientists worldwide. 165 ready-to-use validated skills plus 100 scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nextflow 容器与 Conda 依赖环境实战指南：用 Docker、Singularity/Apptainer、Conda 与 Wave 构建可复现科学流程
Nextflow 容器与 Conda 依赖环境实战指南用 Docker、Singularity/Apptainer、Conda 与 Wave 构建可复现科学流程【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000 scientists worldwide. 165 ready-to-use validated skills plus 100 scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills本文以本仓库 Nextflow 技能中的软件依赖文档为主体系统讲解 Nextflow 如何在每个进程的隔离软件环境中管理依赖如何选择并启用 Docker、Singularity/Apptainer、Podman、Conda 与 Wave 等引擎如何编写container与conda指令以及如何规避多引擎冲突、宿主机文件不可见、HPC 拉取风暴等常见坑。读完本文你将掌握从本地笔记本到 HPC 集群再到云端让科学流程可复现、可移植的完整环境配置方案。为什么要为每个流程隔离软件环境Nextflow 的核心设计目标之一是可复现reproducible与可移植portable。因此它会把每一个process都运行在相互隔离的软件环境中绝不依赖宿主机上手工安装的工具。这样带来的直接收益是可复现同一流程在任何机器上运行使用的都是完全相同版本的镜像或环境发布结果时有据可查可移植流程代码写一次、随处运行——本地、HPCSLURM/SGE/LSF/PBS与云AWS Batch、Google Batch、Azure Batch、Kubernetes之间只切换配置与 profile而不改动流程逻辑可观测每个任务在独立的 work 目录中运行配合-resume缓存与固定版本号问题定位与增量重算都变得简单。这一点在仓库的 Nextflow 技能主文档 中被反复强调One container/conda env per process; never rely on tools installed on the host每个进程一个容器/Conda 环境绝不依赖宿主机工具。而本仓库的 containers.md 原文 则是在 Nextflow 官方容器、Conda 与 Wave 文档的基础上整理的实操型速查手册与 configuration.md配置、执行器、CLI和 running-pipelines.md运行流程、离线执行共同构成配置与扩展这一知识支线。选择引擎先决定运行环境再写流程Nextflow 支持多种容器引擎与包管理器它们在适用场景上差异明显。原文档给出了一张关键决策表这里完整保留并补充说明引擎适用场景启用方式Docker本地开发 / 笔记本 / 有 root 或 docker 组的 CIdocker.enabled trueSingularity / ApptainerHPC 集群无 root、共享文件系统——学术界最常见singularity.enabled true或apptainer.enabled truePodman无 root 的 Docker 替代方案podman.enabled trueCharliecloud / Sarus / Shifter站点特定的 HPC 运行时charliecloud.enabled true等Conda / Mamba没有容器运行时可用需要快速创建环境conda.enabled trueWave从 Conda 配方/Dockerfile 按需构建容器、私有镜像仓库、云端加速wave.enabled true核心铁律一次只启用一个容器引擎。同时打开两个引擎会导致报错或难以预料的行为。nf-core 流水线把各引擎封装成命名 profile用户通常只需在命令行传-profile docker、-profile singularity或-profile conda即可无需手改配置文件。以本仓库 configuration.md 中的 profile 写法为例一个典型的nextflow.config会这样组织profiles { standard { process.executor local } docker { docker.enabled true; docker.runOptions -u $(id -u):$(id -g) } singularity { singularity.enabled true; singularity.autoMounts true } conda { conda.enabled true } slurm { process.executor slurm process.queue compute } test { params.input ${baseDir}/assets/test_samplesheet.csv params.genome R64-1-1 } }运行时用逗号组合多个 profile且顺序敏感后者覆盖前者nextflow run main.nf -profile test,singularity注意容器/基础设施类 profiledocker、singularity、conda互斥只能选一个而test这类数据/profile 可以与引擎组合使用。仓库 SKILL.md 中的最佳实践也建议先跑通内置的testprofile 验证环境再进行真实数据运行。container 指令让每个进程声明自己的镜像引擎决定怎么运行而container指令决定跑什么。每个 process 都可以直接声明它所需的镜像process SAMTOOLS_SORT { container quay.io/biocontainers/samtools:1.19.2--h50ea8bc_0 conda bioconda::samtools1.19.2 // fallback when -profile conda is used script: samtools sort - $task.cpus -o sorted.bam $input }这里的关键是同时声明container和conda使用-profile docker/-profile singularity时走镜像使用-profile conda时走 Conda 环境同一模块在任意引擎下都能工作。nf-core 模块遵循同样的双声明约定但conda指令不是内联字符串而是引用一个独立的environment.yml文件。本仓库 developing.md 中给出了 nf-core 模块的标准写法conda ${moduleDir}/environment.yml // references the file above (NOT inline package strings) container ${ workflow.containerEngine in [singularity, apptainer] !task.ext.singularity_pull_docker_container ? https://depot.galaxyproject.org/singularity/samtools:1.19.2--h50ea8bc_0 : quay.io/biocontainers/samtools:1.19.2--h50ea8bc_0 }对应的environment.yml长这样来自 developing.mdname: samtools channels: - conda-forge - bioconda dependencies: - bioconda::samtools1.19.2值得注意的细节nf-core 模块的container表达式会根据当前引擎自动切换镜像来源——在 Singularity/Apptainer 下优先使用 Galaxy depot 的.sif兼容地址其余情况使用 Biocontainers 的quay.io/biocontainers/...镜像同时通过task.ext.singularity_pull_docker_container允许从 Docker 镜像自动转换。这些镜像都由 Bioconda 配方自动构建标签严格固定到版本号与构建哈希如1.19.2--h50ea8bc_0从而保证不同机器上拿到完全一致的工具。Docker本地开发与 CI 的首选在个人电脑、笔记本电脑或具备 root 权限或用户已加入 docker 组的 CI 上Docker 是最直接的选择。在nextflow.config中启用并设置运行选项docker { enabled true runOptions -u $(id -u):$(id -g) // avoid root-owned output files }runOptions中-u $(id -u):$(id -g)是高频实践默认情况下容器内以 root 运行落盘的输出文件会属于 root导致后续无法清理或读取。显式把当前用户与组 ID 传入即可避免产生 root 属主文件。Singularity / ApptainerHPC 集群的标配在 HPC 集群上用户通常没有 root 权限且各计算节点共享文件系统——这正是 Singularity/Apptainer 的主场也是学术界最常见的部署方式。基础配置如下singularity { enabled true autoMounts true // auto-bind host paths cacheDir /shared/singularity // or set NXF_SINGULARITY_CACHEDIR }几个关键点自动转换与缓存Nextflow 会在首次使用时把 Docker 镜像自动转换为 SIFSingularity Image Format并缓存。在集群上务必设置共享的cacheDir或环境变量NXF_SINGULARITY_CACHEDIR让所有计算节点复用同一次拉取否则每个任务各自下载会导致拉取风暴和配额爆炸。绑定额外路径如果autoMounts true未能自动绑定某些宿主机路径比如独立的/scratch挂载点用runOptions -B /scratch手动补充绑定。工作目录和输入文件所在路径必须处于已绑定的路径上否则 Singularity 任务会看不到输入文件。ApptainerApptainer 即更名后的 Singularity配置项完全一致只是作用域名称改为apptainerapptainer.enabled true。仓库 configuration.md 的环境变量一节也同时列出了NXF_SINGULARITY_CACHEDIR与NXF_APPTAINER_CACHEDIR。关于Singularity 看不到输入文件这一高发问题的排查原文档给出的建议是先确认autoMounts已开启或显式加-B绑定再确认 work 目录与输入文件都位于已绑定的路径集合之内。Conda / Mamba没有容器运行时时的退路当集群或环境完全没有容器运行时可用时Conda/Mamba 是兜底方案。配置如下conda { enabled true useMamba true // faster solver channels conda-forge,bioconda // priority order (this is the default since 26.04) cacheDir /shared/conda_envs } process.conda bioconda::bwa0.7.17 bioconda::samtools1.19要点说明useMamba true使用 Mamba 求解器环境解析速度显著快于默认 Conda 求解器channels按优先级顺序列出频道conda-forge,bioconda是 Nextflow 26.04 以来的默认顺序cacheDir或环境变量NXF_CONDA_CACHEDIR复用已构建的环境避免每个任务重复解析process.conda可以在全局层面为进程声明包依赖也可以在单个 process 内声明。务实的警告Conda 是所有选项中可复现性最差的一种——求解器版本漂移solver drift可能导致相同声明的依赖在不同时间解析出不同版本而且它没有操作系统级隔离。因此对于要发表的结果优先使用容器Conda 只适合没有容器运行时的应急场景。仓库 SKILL.md 也把conda定位为last resort最后手段。Wave Fusion按需构建与云存储加速Wave 与 Fusion 是面向现代云端/HPC 场景的一对组合Wave按需构建或增强容器——可以从conda指令或 Dockerfile 实时构建镜像并推送到镜像仓库还能挂载私有镜像仓库凭据免去手工docker build/push的环节Fusion一个虚拟分布式文件系统让任务像访问本地文件一样读写云对象存储S3/GCS在云执行器上能带来显著的 I/O 加速。wave { enabled true strategy conda // build images from process conda directives } fusion.enabled true // pair with Wave on cloud executors tower.accessToken secrets.TOWER_ACCESS_TOKEN // some Wave features use Seqera credsstrategy conda表示 Wave 直接从各进程的conda指令构建镜像fusion.enabled true通常与 Wave 搭配用于云执行器如 AWS Batch部分 Wave 功能需要 Seqera 平台凭据tower.accessToken。在 configuration.md 的云执行器章节中也明确把Wave Fusion 加速云端 I/O列为云部署的可选增强手段。常见坑与规避清单原文档以实战为导向总结了六大高频问题这里逐一展开同时启用两个引擎→ 会导致报错或难以预料的行为。正确做法是只启用一个引擎且尽量通过 profile 管理参考上文 profiles 示例与仓库 SKILL.md 中container/infra profiles are mutually exclusive的说明。Docker 产生 root 属主输出文件→ 在docker.runOptions中加入-u $(id -u):$(id -g)让容器进程以当前用户身份运行。Singularity 看不到输入文件→ 开启singularity.autoMounts true或通过runOptions -B /path显式绑定并确认 work 目录与输入文件都在已绑定的路径上。HPC 拉取风暴 / 配额爆炸→ 设置共享的NXF_SINGULARITY_CACHEDIR或cacheDir并在有网络的机器上先用nf-core pipelines download预拉取全部镜像详见 running-pipelines.md 的离线执行章节。版本未固定→ 始终使用完整带版本的镜像标签如samtools:1.19.2--h50ea8bc_0条件允许时进一步固定到 digest。使用latest会破坏可复现性——仓库 SKILL.md 明确要求发布科研结果前不要使用latest。离线环境→ 预先准备好全部镜像Singularity SIF 或本地 Docker registry并设置NXF_OFFLINEtrue禁用网络调用。与配置系统、CLI 与离线模式的联动容器配置不是孤立的它与 Nextflow 的配置体系、CLI 工具与运行模式深度耦合。以下几点是原文档之外、从仓库相关文档中可确认的高价值补充用nextflow inspect预检容器解析。无需真正运行流程即可查看每个进程最终解析到哪个容器镜像nextflow inspect pipeline该命令在 configuration.md 的 CLI 参考表中列出适合在提交到 HPC/云之前快速核对镜像地址与引擎选择是否正确。关键环境变量速查摘自 configuration.md变量作用NXF_VER固定本次运行的 Nextflow 引擎版本NXF_SINGULARITY_CACHEDIR/NXF_APPTAINER_CACHEDIRSIF 镜像缓存目录HPC 上务必设置共享目录NXF_CONDA_CACHEDIR缓存的 Conda 环境目录NXF_OFFLINEtrue完全禁用网络调用离线/内网运行NXF_SYNTAX_PARSERv2启用严格语法解析器26.04 起为默认NXF_HOME/NXF_WORK默认家目录 / 默认 work 目录离线air-gapped运行的标准流程。在联网机器上把流水线、配置与容器一起打包nf-core pipelines download nf-core/rnaseq \ --revision 3.14.0 \ --container-system singularity \ # pre-convert images to SIF --compress none \ --outdir nf-core-rnaseq转移到离线机器后export NXF_OFFLINEtrue export NXF_SINGULARITY_CACHEDIR/shared/sif nextflow run nf-core-rnaseq/3_14_0 -profile singularity --input ... --outdir results这条路径与预拉取镜像避免 HPC 拉取风暴是同一思路的两种落地方式完整细节见 running-pipelines.md。仓库内的配套验证。本仓库的 tests/skill-requirements.toml 中[skills.nextflow]一节声明了packages [nf-core]表明该技能在仓库内的验证环境依赖 nf-core 工具链这与运行层面的引擎选择自由度Docker/Singularity/Conda/Wave 任选其一互补——工具链负责开发与校验引擎负责运行时隔离。小结Nextflow 的软件依赖管理遵循一条清晰的主线用container/conda指令在进程级声明依赖用 profile 在运行级选择引擎用固定版本与共享缓存保证可复现与规模化。Docker 负责本地与 CISingularity/Apptainer 接管 HPCConda 作为无容器环境的退路Wave Fusion 面向云端按需构建与加速。只要遵守只启用一个引擎、固定镜像版本、共享缓存目录这三条原则就能让同一套科学流程在任意基础设施上稳定复现。延伸阅读containers.md 原文——本文主体引擎决策表与坑位清单速查SKILL.md——Nextflow 技能总览、安装要求Bash Java 17、运行与开发双模式configuration.md——nextflow.config、scopes、profiles、执行器、缓存与 CLI 全参考running-pipelines.md——样本表、参数文件、iGenomes、离线运行与故障排查developing.md——nf-core 模块的container/conda双声明规范与ext.args约定【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000 scientists worldwide. 165 ready-to-use validated skills plus 100 scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考