From 8ffa4ff640d0830dfe5c2b7c8ec492dc33b66659 Mon Sep 17 00:00:00 2001 From: Ben Sherman Date: Mon, 18 Sep 2023 10:39:20 -0500 Subject: [PATCH] Minor updates Signed-off-by: Ben Sherman --- docs/dsl1.md | 39 ++++++------------------------ docs/getstarted.md | 28 ++------------------- docs/module.md | 2 +- docs/snippets/your-first-script.nf | 26 ++++++++++++++++++++ docs/workflow.md | 14 ++++++++--- 5 files changed, 47 insertions(+), 62 deletions(-) create mode 100644 docs/snippets/your-first-script.nf diff --git a/docs/dsl1.md b/docs/dsl1.md index ce50a4ae38..5635590b3d 100644 --- a/docs/dsl1.md +++ b/docs/dsl1.md @@ -26,7 +26,6 @@ nextflow.enable.dsl=1 params.str = 'Hello world!' process splitLetters { - output: file 'chunk_*' into letters @@ -36,7 +35,6 @@ process splitLetters { } process convertToUpper { - input: file x from letters.flatten() @@ -55,35 +53,8 @@ To migrate this code to DSL2, you need to move all of your channel logic through Refer to the {ref}`workflow-page` page to learn how to define a workflow. The DSL2 version of the above script is duplicated here for your convenience: -```groovy -params.str = 'Hello world!' - -process splitLetters { - - output: - path 'chunk_*' - - """ - printf '${params.str}' | split -b 6 - chunk_ - """ -} - -process convertToUpper { - - input: - path x - - output: - stdout - - """ - cat $x | tr '[a-z]' '[A-Z]' - """ -} - -workflow { - splitLetters | flatten | convertToUpper | view { it.trim() } -} +```{literalinclude} snippets/your-first-script.nf +:language: groovy ``` ## Channel forking @@ -95,7 +66,7 @@ In DSL2, channels are automatically forked when connecting two or more consumers For example, this would not work in DSL1 but is not a problem in DSL2: ```groovy -channel +Channel .from('Hello','Hola','Ciao') .set{ cheers } @@ -116,6 +87,10 @@ In DSL1, the entire Nextflow pipeline must be defined in a single file (e.g. `ma DSL2 introduces the concept of "module scripts" (or "modules" for short), which are Nextflow scripts that can be "included" by other scripts. While modules are not essential to migrating to DSL2, nor are they mandatory in DSL2 by any means, modules can help you organize a large pipeline into multiple smaller files, and take advantage of modules created by others. Check out the {ref}`module-page` to get started. +:::{note} +With DSL2, the Groovy shell used by Nextflow also imposes a 64KB size limit on pipeline scripts, so if your DSL1 script is very large, you may need to split your script into modules anyway to avoid this limit. +::: + ## Deprecations ### Processes diff --git a/docs/getstarted.md b/docs/getstarted.md index 4049a0e694..da47ecb5a9 100644 --- a/docs/getstarted.md +++ b/docs/getstarted.md @@ -96,32 +96,8 @@ nextflow self-update Copy the following example into your favorite text editor and save it to a file named `tutorial.nf`: -```groovy -params.str = 'Hello world!' - -process splitLetters { - output: - path 'chunk_*' - - """ - printf '${params.str}' | split -b 6 - chunk_ - """ -} - -process convertToUpper { - input: - path x - output: - stdout - - """ - cat $x | tr '[a-z]' '[A-Z]' - """ -} - -workflow { - splitLetters | flatten | convertToUpper | view { it.trim() } -} +```{literalinclude} snippets/your-first-script.nf +:language: groovy ``` :::{note} diff --git a/docs/module.md b/docs/module.md index 6d2409ff6c..9cae786a71 100644 --- a/docs/module.md +++ b/docs/module.md @@ -30,7 +30,7 @@ Nextflow implicitly looks for the script file `./some/module.nf`, resolving the Module includes are subject to the following rules: - Relative paths must begin with the `./` prefix. -- Include statements are not allowed from within a worklfow. They must occur at the script level. +- Include statements are not allowed from within a workflow. They must occur at the script level. (module-directory)= diff --git a/docs/snippets/your-first-script.nf b/docs/snippets/your-first-script.nf new file mode 100644 index 0000000000..f457ff3deb --- /dev/null +++ b/docs/snippets/your-first-script.nf @@ -0,0 +1,26 @@ +params.str = 'Hello world!' + +process splitLetters { + output: + path 'chunk_*' + + """ + printf '${params.str}' | split -b 6 - chunk_ + """ +} + +process convertToUpper { + input: + path x + + output: + stdout + + """ + cat $x | tr '[a-z]' '[A-Z]' + """ +} + +workflow { + splitLetters | flatten | convertToUpper | view { it.trim() } +} \ No newline at end of file diff --git a/docs/workflow.md b/docs/workflow.md index fab1b7ec20..ebc3aae4ee 100644 --- a/docs/workflow.md +++ b/docs/workflow.md @@ -41,7 +41,7 @@ The `main:` label can be omitted if there are no `take:` or `emit:` blocks. Workflows were introduced in DSL2. If you are still using DSL1, see the {ref}`dsl1-page` page to learn how to migrate your Nextflow pipelines to DSL2. ::: -## Invoking processes +## Process invocation A process can be invoked like a function in a workflow definition, passing the expected input channels like function arguments. For example: @@ -77,12 +77,12 @@ workflow { ``` :::{warning} -A process can be only be invoked once in a single workflow, unless using {ref}`module-aliases`. +A process can be only be invoked once in a single workflow, however you can get around this restriction by using {ref}`module-aliases`. ::: ### Process composition -Processes with matching input/output declarations can be composed so that the output of the first process is passed as input to the second process. Taking in consideration the previous example, it's possible to write the following: +Processes with matching input/output declarations can be composed so that the output of the first process is passed as input to the second process. The previous example can be rewritten as follows: ```groovy workflow { @@ -134,6 +134,14 @@ workflow { } ``` +When referencing a named output directly from the process invocation, you can use a more concise syntax: + +```groovy +workflow { + ch_samples = foo().samples_bam +} +``` + ### Process named stdout The `emit` option can also be used to name a `stdout` output: