Nextflow将fromFilePairs输入转换为(map,vcf列表,tbi列表)元组方法

原有方案的核心问题 #

• 依赖file.extension判断文件类型逻辑脆弱：Nextflow中file.extension默认只取文件名最后一个.后的内容，.vcf.gz的返回值是gz，极易和其他gz压缩文件混淆
• 多轮groupTuple实现依赖固定分组数量，遇到缺索引、多余文件的情况会直接导致流程挂起，鲁棒性差
• fromFilePairs的设计逻辑是按文件名前缀输出单组[前缀, vcf, tbi]的独立条目，天生不符合“所有vcf归为一个列表、所有tbi归为一个列表”的需求
• multiMap会拆分出多个独立通道，不符合单通道输出要求

可靠实现代码 #

直接通过后缀完整匹配分类文件，收齐后组装三元组，逻辑直白无隐式依赖：

// 读取所有目标文件，按完整后缀分类
Channel
    .fromPath("*.vcf.gz", "*.vcf.gz.tbi")
    .branch {
        vcf: it.name.endsWith('.vcf.gz')
        tbi: it.name.endsWith('.vcf.gz.tbi')
    }
    .set { split_ch }

// 组装为要求的三元组结构
ch_input = split_ch.vcf
    .collect()
    .combine(split_ch.tbi.collect())
    .map { vcfs, tbis ->
        [
            [id: "test"],
            vcfs.sort(),
            tbis.sort()
        ]
    }

实现说明 #

• 用branch算子做文件分类，直接匹配完整文件名后缀，不会误识别其他类型的gz文件，比扩展名判断可靠
• 两类文件分别用collect()收齐为完整列表，再通过combine合并到同一条通道条目，不需要多轮分组操作
• 对两个文件列表增加sort()排序，避免文件系统遍历顺序随机导致的vcf和tbi顺序错位
• 执行ch_input.view()即可得到完全符合要求的输出结构：

  [
      [id:test],
      [/work/path/a.vcf.gz, /work/path/b.vcf.gz, /work/path/c.vcf.gz],
      [/work/path/a.vcf.gz.tbi, /work/path/b.vcf.gz.tbi, /work/path/c.vcf.gz.tbi]
  ]
  

• 如果后续需要增加分组维度（比如按批次、样本分组），只需要在collect前传入分组key即可，不需要重构整体逻辑。

内容的提问来源于stack exchange，提问作者Einar