Skip to content

[Proposal] Move CLI commands for project management to subcommands #5959

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

Open
bentsherman opened this issue Apr 10, 2025 · 5 comments
Open

Comments

@bentsherman
Copy link
Member

As we add several new commands like inspect, linting, formatting, data provenance, the CLI is getting crowded.

There are several commands for managing pipeline projects:

  • clone
  • drop
  • list
  • pull
  • view

I think all of these commands could be combined into a single command e.g. projects or repos:

nextflow projects list
nextflow projects pull <project>
nextflow projects view <project>
...

Similar to what we are doing in #5715

We can keep the existing commands as redirects and hide them in the CLI help, so it should be easy to transition.

@pditommaso
Copy link
Member

It's too boring to type ..

@pditommaso
Copy link
Member

i'd suggest to keep linting check and format into a single command

@bentsherman
Copy link
Member Author

Why don't we do both:

  • combine check and format into a single command lint with option to apply formatting
  • move project management commands under a single command (note that lint and list are very similar)

I think it is inevitable for them to be grouped under a single command. It is increasingly necessary for other commands:

  • cid (perhaps it will be called data or prov)
  • fs for filesystem operations
  • plugin (likely to expand with the plugin registry)
  • secrets for managing secrets

Why shouldn't these project management commands be subject to the same pattern?

Top-level commands should be reserved for the most commonly used commands like run and info (likely also lint as well). Do you really think commands like list and view are used often enough for them to be top-level commands?

@pditommaso
Copy link
Member

Ok, fair enough. Let's begin with the lint one, and do the projects one in a separate step

@pditommaso
Copy link
Member

We may need to keep at least pull with a deprecation notice for some time to avoid breaking changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants