You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/process-typed.md
+115-1Lines changed: 115 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -65,6 +65,8 @@ All {ref}`standard types <stdlib-types>` except for the dataflow types (`Channel
65
65
66
66
Nextflow automatically stages `Path` inputs and `Path` collections (such as `Set<Path>`) into the task directory.
67
67
68
+
### Nullable inputs
69
+
68
70
By default, tasks fail if any input receives a `null` value. To allow `null` values, add `?` to the type annotation:
69
71
70
72
```nextflow
@@ -85,10 +87,84 @@ process cat_opt {
85
87
}
86
88
```
87
89
88
-
### Stage directives
90
+
### Record inputs
91
+
92
+
Inputs with type`Record` can declare the name and type of each record field:
93
+
94
+
```nextflow
95
+
process fastqc {
96
+
input:
97
+
(id: String, fastq: Path): Record
98
+
99
+
script:
100
+
"""
101
+
echo 'id: ${id}`
102
+
echo'fastq: ${fastq}'
103
+
"""
104
+
}
105
+
```
106
+
107
+
This pattern is called *record destructuring*. Each record field is staged into the task the same way as an individual input.
108
+
109
+
When the process is invoked, the incoming record should contain the specified fields, or else the run will fail. If the record has additional fields not declared by the process input, they are ignored.
110
+
111
+
:::{tip}
112
+
Record inputs are a useful way to selecta subset of fields from a larger record. This way, the process only stages what it needs, allowing you to keep related data together in your workflow logic.
113
+
:::
114
+
115
+
### Record type inputs
116
+
117
+
Record inputs can also be declared using a custom record type:
118
+
119
+
```nextflow
120
+
process fastqc {
121
+
input:
122
+
sample: Sample
123
+
124
+
script:
125
+
"""
126
+
echo 'id: ${sample.id}`
127
+
echo'fastq: ${sample.fastq}'
128
+
"""
129
+
}
130
+
131
+
record Sample {
132
+
id: String
133
+
fastq: Path
134
+
}
135
+
```
136
+
137
+
In this example, the record is staged into the task as `sample`, and `sample.fastq` is staged as an input file since the `fastq` field is declared with type`Path`.
138
+
139
+
When the process is invoked, the incoming record should contain the fields specified by the record type, or else the run will fail. If the record has additional fields not declared by the record type, they are ignored.
140
+
141
+
### Tuple inputs
142
+
143
+
Inputs with type`Tuple` can declare the name of each tuple component:
144
+
145
+
```nextflow
146
+
process fastqc {
147
+
input:
148
+
(id, fastq): Tuple<String,Path>
149
+
150
+
script:
151
+
"""
152
+
echo'id: ${id}`
153
+
echo 'fastq: ${fastq}'
154
+
"""
155
+
}
156
+
```
157
+
158
+
This pattern is called *tuple destructuring*. Each tuple component is staged into the task the same way as an individual input.
159
+
160
+
The generic types inside the `Tuple<...>` annotation specify the type of each tuple compomnent and should match the component names. In the above example, `id` has type `String` and `fastq` has type `Path`.
161
+
162
+
## Stage directives
89
163
90
164
The `stage:` section defines custom staging behavior using *stage directives*. It should be specified after the `input:` section. These directives serve the same purpose as input qualifiers such as `env` and `stdin` in the legacy syntax.
91
165
166
+
### Environment variables
167
+
92
168
The `env` directive declares an environment variable in terms of task inputs:
93
169
94
170
```nextflow
@@ -106,6 +182,8 @@ process echo_env {
106
182
}
107
183
```
108
184
185
+
### Standard input (stdin)
186
+
109
187
The `stdin` directive defines the standard input of the task script:
110
188
111
189
```nextflow
@@ -123,6 +201,8 @@ process cat {
123
201
}
124
202
```
125
203
204
+
### Custom file staging
205
+
126
206
The `stageAs` directive stages an input file (or files) under a custom file pattern:
127
207
128
208
```nextflow
@@ -222,6 +302,40 @@ process foo {
222
302
}
223
303
```
224
304
305
+
### Structured outputs
306
+
307
+
Whereas legacy process outputs could only be structured using specific qualifiers like `val` and `tuple`, typed process outputs are regular values.
308
+
309
+
The `record()` standard library function can be used to create a record:
310
+
311
+
```nextflow
312
+
process fastqc {
313
+
input:
314
+
(id: String, fastq: Path): Record
315
+
316
+
output:
317
+
record(id: id, fastqc: file('fastqc_logs'))
318
+
319
+
script:
320
+
// ...
321
+
}
322
+
```
323
+
324
+
The `tuple()` standard library function can be used to create a tuple:
325
+
326
+
```nextflow
327
+
process fastqc {
328
+
input:
329
+
(id, fastq): Tuple<String,Path>
330
+
331
+
output:
332
+
tuple(id, file('fastqc_logs'))
333
+
334
+
script:
335
+
// ...
336
+
}
337
+
```
338
+
225
339
## Topics
226
340
227
341
The `topic:` section emits values to {ref}`topic channels <channel-topic>`. A topic emission consists of an output value and a topic name:
The following operations are supported for records:
790
+
791
+
`+ : (Record, Record) -> Record`
792
+
: Given two records, returns a new record containing the fields and values of both records. When a field is present in both records, the value of the right-hand record takes precedence.
793
+
794
+
`- : (Record, Iterable<String>) -> Record`
795
+
: Given a record and a collection of strings, returns a copy of the record with the given fields removed.
796
+
797
+
The following methods are available for a record:
798
+
799
+
`subMap( keys: Iterable<String> ) -> Record`
800
+
: Returns a new record containing only the given fields.
Copy file name to clipboardExpand all lines: docs/strict-syntax.md
+24-8Lines changed: 24 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,14 +50,29 @@ def json = new groovy.json.JsonSlurper().parseText(json_file.text)
50
50
51
51
Some users use classes in Nextflow to define helper functions or custom types. Helper functions should be defined as standalone functions in Nextflow. Custom types should be moved to the `lib` directory.
52
52
53
-
:::{note}
54
-
Enums, a special type of class, are supported, but they cannot be included across modules at this time.
55
-
:::
53
+
You can use an enum type to model a choice between a fixed set of categories:
56
54
57
-
:::{note}
58
-
Record types will be addressed in a future version of the Nextflow language specification.
55
+
```nextflow
56
+
enum Color {
57
+
RED,
58
+
GREEN,
59
+
BLUE
60
+
}
61
+
```
62
+
63
+
:::{versionadded} 26.04.0
59
64
:::
60
65
66
+
You can use a record type to model a composition of multiple values:
67
+
68
+
```nextflow
69
+
record FastqPair {
70
+
id: String
71
+
fastq_1: Path
72
+
fastq_2: Path
73
+
}
74
+
```
75
+
61
76
### Mixing script declarations and statements
62
77
63
78
In the strict syntax, a script may contain any of the following top-level declarations:
@@ -230,13 +245,14 @@ In the strict syntax, use `System.getenv()` instead:
230
245
println "PWD = ${System.getenv('PWD')}"
231
246
```
232
247
233
-
:::{versionadded} 24.04.0
234
-
The `env()` function should be used instead of `System.getenv()`:
248
+
:::{versionadded} 25.04.0
249
+
:::
250
+
251
+
Use the `env()` function instead of `System.getenv()`:
0 commit comments