Simplify process entry execution #6391
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add support for executing Nextflow processes directly without explicit workflow definitions. Key Features: - Single process scripts run automatically: `nextflow run script.nf --param value` - Multi-process scripts use entry selection: `nextflow run script.nf -entry process:name --param value` - Automatic command-line parameter mapping to process input channels - Support for all standard input types: val, path, env, tuple, each - Comprehensive error handling with helpful suggestions Implementation: - Enhanced BaseScript with process entry workflow generation - Added parameter mapping pipeline with input definition extraction - Created specialized delegates for parsing compiled process bodies - Added ScriptMeta methods for single/multi-process detection - Comprehensive documentation and test coverage This feature bridges the gap between command-line tools and workflow orchestration, making Nextflow processes more accessible for direct execution scenarios. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]> Signed-off-by: Paolo Di Tommaso <[email protected]>
Signed-off-by: Paolo Di Tommaso <[email protected]>
- Rename ProcessEntryHelper.groovy to ProcessEntryHandler.groovy for clearer naming - Update all class references in BaseScript.groovy to use ProcessEntryHandler - Clean separation of process entry execution feature from main BaseScript class - All functionality preserved: single process auto-execution and multi-process entry selection 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Signed-off-by: Paolo Di Tommaso <[email protected]>
Signed-off-by: Paolo Di Tommaso <[email protected]>
Signed-off-by: Paolo Di Tommaso <[email protected]>
--------- Signed-off-by: Rob Syme <[email protected]> Signed-off-by: Ben Sherman <[email protected]> Co-authored-by: Ben Sherman <[email protected]>
Add defensive null checking for sender thread and workflowId to prevent NullPointerException when onFlowComplete is called after initialization failures in onFlowCreate or onFlowBegin methods. Signed-off-by: Rob Syme <[email protected]> Co-authored-by: Ben Sherman <[email protected]>
Signed-off-by: Paolo Di Tommaso <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR simplifies the parsing of process inputs in #6381 by applying a refactor that was originally developed for #6368 .
Instead of creating an on-the-fly closure delegate in the process entry handler, it is much simpler to use the process inputs after they are parsed into
InParams.The problem is that the process inputs normally aren't constructed until the process is invoked by a workflow. Instead, we need to construct them when the ProcessDef is constructed.
At the same time, the process config still needs to be applied at invocation, since config settings can use
withNameselectors which depend on the execution context.To do this, we factor out several classes from ProcessConfig:
ProcessDsl: defines the DSL for inputs, outputs, and directivesProcessConfigBuilder: provides functions for applying process config settingsProcessBuilderbase class containing shared logic for these two classesThis allows us to build the ProcessDef and resolve the process body immediately, while still applying the process config only after the process is invoked. It also greatly simplifies the process entry handler.
NOTE: In #6368 , ProcessDsl becomes ProcessDslV1, and a separate ProcessDslV2 is defined for the static type syntax.