Options for guix workflow run

This is the command to run (or prepare to run) a workflow from a file. It generate the process scripts, builds or downloads all dependencies, and then runs the workflow process scripts corresponding to the workflow defined in the given file.

The following options can be provided to change the behavior of this command.

-i name[=file]

A workflow may have so-called free inputs, inputs that are not provided by any of the workflow’s processes. By default, the GWL will pick files from the current working directory that match the names of free inputs. This option can be used to map a file with an arbitrary name to a free input in the workflow with the given name. This option can be provided more than once.

In the following example, the free input called genome is mapped to the file /data/hg19.fa before running the workflow defined in analysis.w:

guix workflow run --input=genome=/data/hg19.fa analysis.w

The workflow in analysis.w could look something like the following. Note the input file genome, which is an input not provided by any other processes, and which must hence be provided through the command line.

process state-the-obvious
    . "genome"
    . "result"
  # {
    echo "This is a genome: {{inputs}}" > {{outputs}}

    list state-the-obvious
-o location

This option currently has no effect.

-e engine

Select the process engine engine as the target of the generated process scripts. See Process Engines.

-p file

Generate the process scripts and build or download all dependencies, but do not run the workflow process scripts corresponding to the workflow defined in file.

-l events,…

Print messages for the comma-separated list of events. This defaults to logging the events error, execute (for fatal errors) (for processes that are run), and info (for status information). The following log events exist: error, info, execute, cache, debug, and guix. The special event type all enables all logging.


Prepare the scripts and the environments but don’t actually run the processes. Only show what commands would be run.


Execute all processes, even if their outputs may have been cached from previous runs.


Run each process inside of an isolated environment with file system virtualization and user namespaces. Only declared input files will be available at execution time, and only declared output files will be stored. This is a great option to use when you want to make sure that your processes only depend on state that you have declared. A downside is that generated output files cannot be written to the target directories directly but are copied from the container to the file system.