Named arguments for processes and workflows #3712
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #2257 #3507
Adds a
take
option for process inputs that is similar to theemit
option for outputs. Processes and workflows can now be invoked with named arguments, using the same syntax as native Groovy functions.Additionally, you don't have to specify the
take
option in the input declaration if the process input has a simple name. For inputs with e.g. GStrings, closures, tuples, thetake
option must be explicit.It works by interpreting the first process / workflow argument as the named arguments map if it is a map. We have to do this because the invocation happens through
WorkflowBinding.invokeMethod()
rather than an actual function definition. So there will be a problem if you call a process and the first argument is a map, but you meant for that argument to be for the first process input (i.e. as a value channel).One way that we could avoid this problem is to refactor the NextflowDSL AST transformation to convert process and workflow definitions into actual function definitions, so that the process/workflow inputs are defined as native function arguments.