Separate CLI from runtime

[bentsherman]

This PR splits the nextflow module into two modules:

• nextflow: contains only the Launcher and CLI classes
• nf-runtime: contains everything (i.e. the "runtime")

Benefits:

• Improves build time, editing CLI code doesn't rebuild the entire project
• Removes some circular dependencies, making the code easier to read/understand
• Library consumers like platform or plugins can just depend on the runtime and not the CLI
• Makes it easier to implement a CLI v2 in the future

I left ConfigBuilder in the CLI module for now because it is a tangled mess. In a follow-up PR I would like to separate the "core" ConfigBuilder from the extra CLI logic (e.g. ConfigCliAdapter)

Note to self: could also keep nextflow as it is and move the CLI code into a separate module e.g. nextflow-cli.

[netlify[bot]]

✅ Deploy Preview for nextflow-docs-staging canceled.

Name	Link
🔨 Latest commit	43053fb70bc98cf7d9da69e438d411a58a9a5d7d
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs-staging/deploys/686e700078338e0008cc8729

[bentsherman]

Due to the nature of this PR, I will keep it updated via rebase instead of merge commits so that the changes are as clear as possible.

[pditommaso]

oh mamma mia 😆

[bentsherman]

Your k8s plugin inspired me 😄

[pditommaso]

I feared that 😆

[bentsherman]

Jokes aside, it might be good to do the actual code changes in a separate PR so that the nf-runtime part is as clean as possible

The nf-runtime refactor was just the easiest way to reveal the circular dependencies

[pditommaso]

I'll review post 25.04

[bentsherman]

Refactored so that the CLI code is in a new module nf-cli-v1. Made the PR considerably smaller

Note the following plugins depend explicitly on the CLI code because they add CLI commands:

• nf-console
• nf-k8s
• nf-tower
• nf-wave

Might be possible to remove this dependency by moving some interfaces into the core runtime, but not a big deal either way

[bentsherman]

I refactored the nf-lineage module to depend on nextflow and be required by nf-cli-v1. This removes the need for the LinCommand interface as the lineage command can simply use LinCommandImpl directly.

Couldn't quite do this for nf-k8s because the K8sDriverLauncher uses CmdRun, so that's a pretty hard dependency on the CLI v1. We could make nf-k8s a module instead of a plugin, but then it would be included at build-time instead of runtime.

[pditommaso]

Did I break anything? I see some tests failing. Also trying locally I get

» ./launch.sh run hello

 N E X T F L O W   ~  version 25.06.0-edge

NOTE: Your local project version looks outdated - a different revision is available in the remote repository [2ce0b0e294]
Launching `https://github.com/nextflow-io/hello` [backstabbing_ride] DSL2 - revision: afff16a9b4 [master]

ERROR ~ No such variable: session

[bentsherman]

Did I break anything? I see some tests failing. Also trying locally I get

Actually that's my fault, looks like a regression from #6257 . I will submit a separate fix

[bentsherman]

Found some possible solutions for decoupling nf-k8s, nf-tower, and nf-wave from CLI v1. See top comment for details.