-
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? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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 <bentshermann@gmail.com>
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
.