DeBasher: a flow-based programming bash extension for the implementation of complex and interactive workflows with stateful processes

Table 1 Comparison of WfMs

	CWL\(^1\)	WDL\(^2\)	Nextflow	Snakemake	Scipipe	Cylc	DeBasher
Platform	CWL	WDL	Groovy	Python	Go	Cylc	Bash
Built-in multilanguage\(^3\)	Bash	Bash	Any	Bash	Bash	Bash	Any
CWL\(^4\)	Yes	NA	No	No	No	No	No
Workflow modules	Yes	Yes	Yes	Yes	Yes	Yes	Yes
GUI	Yes	Yes	Yes	Yes	No	Yes	No
Graph rendering	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Reproducibility	Yes	Yes	Yes	Yes	No	No	Yes
Batch schedulers	Yes	Yes	Yes	Yes	Restricted\(^5\)	Yes	Yes
Distributed clusters	Yes	Yes	Yes	Yes	No	Yes	No
Cloud	Yes	Yes	Yes	Yes	No	Yes	Yes
Data streams	Yes	No	No	Yes	Yes	No	Yes
Stateful processes	No	No	No	No	No	No	Yes
Static scheduling	No	No	No	No	No	No	Yes
Dynamic scheduling	Stateless	Stateless	Stateless	Stateless	Stateless	Stateless	Stateful
Support for cycles	No	No	Exper\(^6\)	Stateless	Stateless	Stateless	Stateful
User-defined triggers\(^7\)	No	No	No	No	No	Stateless	Stateful
Interactive workflows	No	No	No	No	No	No	Yes
Runtime piping	No	No	No	No	No	No	Yes

\(^1\)CWL implemented with Toil
\(^2\)WDL implemented with Cromwell
\(^3\)Built-in support to execute code in multiple languages, meaning that the workflow language provides built-in syntax and features that facilitate the direct execution of tasks in different languages, making it more seamless and transparent. This contrasts with more basic integration mechanisms, where manual invocation (e.g., calling an external script or using shell commands) is required
\(^4\)Support for Common Workflow Language
\(^5\)According to the documentation, the feature is under development
\(^6\)This feature is currently classified as experimental in the tool’s documentation
\(^7\)The ability of the system to work with triggers arbitrarily defined by the user (more standard triggers, such as workflow or step reexecution due to changes in source code or input parameters, that require the user to explicitly invoke the WfM are not considered here)

ISSN: 1471-2105