1. Bioinformatics often begins as shell commands
In practice, many bioinformatics analyses do not begin with a workflow file. They begin with a line typed into a terminal, a small script copied from an older project, or a command found in a README:
fastqc sample.fq.gz
bwa mem ref.fa reads.fq.gz
samtools sort aln.bam
blastp -query protein.fa -db nr
minimap2 ref.fa reads.faOver time, those lines end up in server directories, shell history, methods sections, GitHub README files, lab notes, container recipes, HPC module systems, and informal knowledge passed between people. They may be enough to finish one analysis, but not enough to make that analysis easy to rerun somewhere else.
The problem underneath workflow design is that many everyday commands have no durable execution object: no fixed version, no closed runtime, no clear distribution path, and no easy way to inspect what will actually run.
2. TAFFISH is a shell-native execution and delivery layer
This is why TAFFISH is best described at the command execution layer. It is not primarily another workflow system, a conventional package manager, a container wrapper, or a web platform. Its role is narrower and, for daily bioinformatics work, more basic: turn a shell-based tool invocation into an executable package that can be installed, inspected, rerun, and shared.
The name TAFFISH stands for Tools And Flows Framework Intensify SHell.
TAFFISH is a shell-native reproducible execution and delivery layer for bioinformatics command-line tools and lightweight workflows.
The goal is not to pull users out of shell. The goal is to make the commands already used in shell carry enough structure to be reproduced by someone else.
3. Why TAFFISH stays close to Shell
Shell is still the floor of much bioinformatics computing. Even when a project uses Nextflow, Snakemake, Galaxy, CWL, Python, R, or an HPC scheduler, many tasks eventually become command-line tool invocations.
Wrapping command-line tools is not new. CWL, Boutiques, Galaxy wrappers, Snakemake wrappers, nf-core modules, shpc, and BioContainers all address this space from different directions. TAFFISH takes a particular route: it keeps shell as the first working surface.
TAFFISH brings reproducibility back to shell commands instead of moving those commands into a separate working surface first.
A TAFFISH command still looks like a normal shell command:
taf update
taf install samtools
taf info samtools
taf-samtools samtools view --helpThe visible shape is familiar. What changes is the information attached to the command: version, container, parameters, backend, metadata, and Hub distribution records.
4. TAFFISH complements existing systems from a lower layer
The comparison is not a ranking. These systems solve different parts of reproducible computing. TAFFISH is meant to cover a lower layer that many of them eventually depend on: the command that actually runs.
| System or technology | Main layer | Relationship to TAFFISH |
|---|---|---|
| Nextflow / Snakemake | Workflow orchestration | TAFFISH commands can serve as reproducible command bricks inside workflow tasks. |
| Galaxy | Web platform | Galaxy brings tools into a web platform; TAFFISH brings reproducibility back to shell commands. |
| Conda / Bioconda | Software installation | Bioconda installs software; TAFFISH packages how software is reproducibly executed as a command. |
| Docker / Podman / Apptainer | Runtime environment | Containers provide the runtime closure; TAFFISH binds that closure to command interfaces and Hub metadata. |
| CWL / WDL / Boutiques | Descriptor standards | These systems describe portable tools; TAFFISH emphasizes shell-native use and executable package delivery. |
| shpc / BioContainers | Containerized command exposure | TAFFISH exposes commands while also binding parameters, metadata, releases, trust signals, and flow interfaces. |
5. The core model is the executable package
The important object in TAFFISH is not just a software binary, and not just an executable inside a container. The important object is the command as something that can be installed and run with known execution semantics.
In practice, a TAFFISH executable package can bind together:
- tool identity and command interface;
- parameter schema and help-facing semantics;
- version and release metadata;
- container image, backend resolution, mounts, and workdir behavior;
- platform constraints and dependency information;
- smoke metadata, digest information, and Hub trust records;
- an installable shell command and optional composable flow interface.
A traditional package manager mostly asks how software is installed. TAFFISH asks one step later: after the software exists, how does it become a reproducible command?
6. What TAFFISH is not
The boundaries matter. TAFFISH has flows, but it is not primarily a workflow orchestrator. Complex DAG scheduling, task caching, cloud execution, and scheduler-level resource orchestration remain the territory of workflow engines.
It is also not a claim that the whole shell universe can become perfectly reproducible. Shell is too open for that: filesystems, networks, randomness, time, permissions, hardware, and user state still matter. The claim is more precise:
TAFFISH provides reproducible execution packaging for shell-based bioinformatics commands.
7. Core use cases
For users, the first benefit is simple: tools become
ordinary-looking taf-* commands, but their runtime
environment and package metadata are already attached.
In everyday use, the change can be deliberately small. A naked
command such as blastp ... can be replaced by a
TAFFISH-provided entry such as
taf-blast-v2.17.0-r1 blastp ..., or by the command
name declared by that app. To a shell script, Perl script, Python
subprocess call, or host-level Nextflow/Snakemake task, it is
still just a shell command; the difference is that the command is
now bound to TAFFISH metadata, container resolution, and release
semantics.
For tool developers, TAFFISH turns a command invocation, its parameters, container runtime, release, and validation metadata into something more durable than a README example.
For workflow builders, TAFFISH commands can be assembled into lightweight taf flows, embedded in shell scripts, or called from Nextflow and Snakemake as ordinary commands with stronger execution semantics. If the surrounding workflow task itself runs inside another container, the TAFFISH command must be available at that execution boundary; TAFFISH does not automatically enter an unrelated closed container.
8. TAFFISH-HUB makes executable packages discoverable
TAFFISH-HUB is where these executable packages become discoverable. App repositories provide structured metadata, versioned releases, container image references, dependencies, platform constraints, smoke metadata, upstream source metadata, and trust signals.
The generated index is consumed by local taf
commands. Users update the index, inspect package metadata,
install apps, and run commands on their own machines or servers.
The current Hub is intentionally static and GitHub-based. That is
not the only possible future, but it keeps the publishing path
transparent and auditable today.
9. In one sentence
A compact way to describe TAFFISH is this: it is a command-level reproducibility layer for bioinformatics tools and lightweight workflows.
TAFFISH brings reproducibility back to the shell commands bioinformaticians already use.
Its core is not replacement, but completion. It gives tools, flows, Hub metadata, security checks, AI-facing inspection, and future ecosystem work a more stable command layer to stand on.