Each DRAGEN tool has a single schema.yaml under inst/config/tools/<tool>/. See https://tidywf.github.io/nemo/articles/structure.html for a walkthrough of the Tool/Workflow/Config class structure and schema contents.
tidydragen adds one intermediate base, DragenTool (inheriting nemo::Tool), which all domain tools extend. It carries the DRAGEN-shared parsing logic, most notably the dragen-metrics filetype that handles the headerless section,rg,variable,count[,pct] shape common to DRAGEN *_metrics.csv files. See the UML article for the class diagram.
Why several tools, not one
DRAGEN emits its outputs in functional groups: mapping, coverage, variant calling, RNA quantification, per-read FastQC, and the ctTSO500 app layer. Rather than a single monolithic Dragen tool bundling every schema, tidydragen gives each group its own tool (DragenMap, DragenCov, DragenVar, DragenRna, DragenFqc, DragenTso), for a few reasons:
- Pipelines produce different subsets. A germline-only run has no somatic SV or RNA fusion outputs; an RNA-only run has no variant calling. The
Dragenworkflow registers all six and tolerates absent files, so each pipeline simply yields the tables it has, with no all-or-nothing coupling. - One tool, one
schema.yaml, one output category. Each tool owns a single, focused schema scoped to its group; the tool name becomes the category token in every output name (e.g.<prefix>_dragencov_finehist), so a table’s origin is self-documenting. - Independent evolution. Adding, versioning, or fixing one group’s schema touches only that tool, keeping the shared metrics logic on the
DragenToolbase untouched.
The shared machinery still lives in one place. Everything common (the dragen-metrics/csv-nohead filetypes, the refine_files prefix logic, the fail-loud policies) sits on the DragenTool base and is inherited by all, so splitting the tools costs no duplication.