-
Notifications
You must be signed in to change notification settings - Fork 685
Separate CLI from runtime #5971
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
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. |
oh mamma mia 😆 |
Your k8s plugin inspired me 😄 |
I feared that 😆 |
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 |
I'll review post 25.04 |
Refactored so that the CLI code is in a new module Note the following plugins depend explicitly on the CLI code because they add CLI commands:
Might be possible to remove this dependency by moving some interfaces into the core runtime, but not a big deal either way |
ac8c183
to
bf822ef
Compare
Signed-off-by: Ben Sherman <[email protected]>
This PR splits the nextflow module into two modules:
nextflow
: contains only the Launcher and CLI classesnf-runtime
: contains everything (i.e. the "runtime")Benefits:
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
.