-
Notifications
You must be signed in to change notification settings - Fork 695
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
b4b321e
to
069653d
Compare
83f7d30
to
5cc1731
Compare
Signed-off-by: Ben Sherman <[email protected]>
I refactored the Couldn't quite do this for |
This PR splits the nextflow module into two modules:
nf-cli-v1
: contains only the Launcher and CLI classesnextflow
: contains everything (i.e. the "runtime")Benefits:
I separated the CLI bits in
ConfigBuilder
into a separate classConfigCmdAdapter
in order to keep the core config builder in the runtime. This also provides a nice separation of concerns.