TraitWeaver: a Nextflow pipeline for microbial trait prediction
- Genomesinput
- Quality checkfilter
- Gene annotationbackbone
- Trait prediction6 tools, in parallel
- One joined tableoutput
A microbial genome passed through half a dozen annotation tools produces half a dozen incompatible formats: a TSV with a bespoke header, a GenBank file, a JSON blob and a directory of per-genome folders. Each answers a different question, and none of them join.
TraitWeaver is a Nextflow DSL2 pipeline that runs those tools and normalises what comes out. Every module writes Parquet tables that share a common set of keys, so results from different tools can be queried together.
Without shared keys, every question needs its own parser
The work behind the pipeline is comparative. We take a few hundred assembled genomes and ask which of them carry a given trait. With raw tool outputs, that means writing a one-off script for each tool and each question, and rewriting it whenever a tool is added. The identifiers do not line up either. Bakta uses locus tags, DRAM uses its own gene ids, and antiSMASH numbers regions separately, so a question such as “which genes in this biosynthetic region received a KEGG ortholog” becomes a text-processing problem instead of a join. Learning traits from tables of this shape is separate work, described in predicting what a microbe eats from its genome.
Annotation runs are also slow. antiSMASH and DRAM are the usual bottlenecks, and with every module enabled a single genome can take anywhere from under an hour to several hours. At that cost, a pipeline that has to be rerun from scratch whenever a module is added is not practical.
One quality check, one annotation backbone, then a fan-out
CheckM2 assesses genome quality before Bakta establishes a common annotation backbone. Proteins and genome records then fan out to complementary analyses.
| Module | What it adds |
|---|---|
| CheckM2 | Genome completeness and contamination |
| Bakta | Genes, contigs and baseline functional annotation |
| KOfamScan | KEGG ortholog assignments |
| eggNOG-mapper | Orthology-based functional annotation |
| PGPT | Plant growth-promoting traits |
| antiSMASH | Biosynthetic gene clusters |
| DRAM | Metabolism-oriented annotation |
| GTDB-Tk | Genome taxonomy |
Every module produces Parquet tables with shared genome, gene, contig and region identifiers. That common key space turns otherwise incompatible outputs into a single dataset. Genes can be joined to pathways, biosynthetic regions, taxonomies and predicted traits without writing a new parser for each question.
Pinned environments and separate run directories make reruns safe
Each tool has its own environment, pinned and built ahead of time rather than solved when the pipeline runs. Environments resolved at run time are a common reason that a pipeline which worked last month no longer works.
A run writes into its own directory and does not touch the accumulated dataset. Promoting a run into that dataset is a separate and deliberate step. Annotation takes hours per genome and sometimes fails partway, so it matters that a bad run cannot overwrite good results.
Genomes that fail the quality check stop at that point, but they remain in the quality table with the reason recorded. A genome missing from the results can then be explained without tracing it back through the logs.
The reference vocabularies are loaded as tables in their own right: KEGG orthologs, PGPT traits, antiSMASH product types. Holding them as tables rather than as strings inside each tool’s output is what allows a question to be asked about a category rather than about a particular spelling.