Skip to content

[WiP] moss: switch cli to use clap derive structs - #687

Draft
ermo wants to merge 25 commits into
mainfrom
ermo/task/moss-refactor-cli-approach
Draft

[WiP] moss: switch cli to use clap derive structs#687
ermo wants to merge 25 commits into
mainfrom
ermo/task/moss-refactor-cli-approach

Conversation

@ermo

@ermo ermo commented Feb 5, 2026

Copy link
Copy Markdown
Member

This PR migrates the CLI from function-based Clap declarations to clap_derive. clap_derive allows a declarative-like definition of the CLI command tree, so it's easier to maintain and extend.

Inside moss/src/cli we'll have a root mod.rs file and one module per each subcommand. Modules may be split into other submodules when the logic becomes complex and/or multiple tests are defined (e.g. for the package subcommand).
Each module will have a Command struct with handle() as its only public method. The signature of each handle() is not identical for all Commands, but depends on the logic it performs.
Public structs/enum/functions will be at the top of each source file, private ones will be right below.

This PR fixes #196, but that issue plan functionalities that the moss backend does not yet support, and that's the reason why you'll see a bunch of unimplemented!() calls across the PR.
It also fixes #611.

Another thing I wanted to make consistent is the use verbs in their imperative conjugation instead of third-person, as these are commands. I also chose not to end phrases with a dot, like most programs out there.

I think the code could be cleaned a little (e.g. there are some Vec conversions I'm not sure they would be needed with more generic code), but that's out of the scope of this PR. I'm trying to introduce no functional and API changes here, except the parsing of CLI arguments: where possible, I'm leveraging Clap's automatic call of TryFrom to sanitize inputs, particularly for providers where I'm now passing the Provider struct.

TODO: print final CLI tree.

@ermo
ermo force-pushed the ermo/task/moss-refactor-cli-approach branch 4 times, most recently from b8a732b to 1d81a7f Compare March 15, 2026 17:11
@ermo
ermo force-pushed the ermo/task/moss-refactor-cli-approach branch 2 times, most recently from 15db4d6 to ff813c4 Compare April 15, 2026 13:54
@livingsilver94
livingsilver94 force-pushed the ermo/task/moss-refactor-cli-approach branch 11 times, most recently from ff776d2 to 8978b24 Compare August 6, 2026 19:51
@livingsilver94
livingsilver94 force-pushed the ermo/task/moss-refactor-cli-approach branch 8 times, most recently from d9f7098 to 7b91bad Compare August 25, 2026 22:20
ermo added 4 commits August 26, 2026 00:22
Not done yet, just capturing current progress.

Signed-off-by: Rune Morling <ermo@aerynos.com>
Signed-off-by: Rune Morling <ermo@aerynos.com>
Signed-off-by: Rune Morling <ermo@aerynos.com>
Signed-off-by: Rune Morling <ermo@aerynos.com>
@livingsilver94
livingsilver94 force-pushed the ermo/task/moss-refactor-cli-approach branch from 7b91bad to 968cece Compare August 25, 2026 22:22
Rune said:

  "--upgrade-only is a misfeature.
  An index is supposed to be ABI-complete.
  Having packages installed from a previous index is thus ungood."

And who am I to disagree!
cli::Error is currently 144 bytes large and clippy complains about that.
To silence it, we heap allocate it.

I consider this half a hack and we should ideally reduce Error's size,
starting from client::Error.
@livingsilver94
livingsilver94 force-pushed the ermo/task/moss-refactor-cli-approach branch from 968cece to 331a69d Compare August 26, 2026 20:10
@ermo

ermo commented Aug 28, 2026

Copy link
Copy Markdown
Member Author

The moss package inspect alias (pin) might need to change, as the plan is to add an actual moss package pin command that saves a package in a default highest-priority cobble repo and keeps it there until the user removes it (which will typically happen when it causes the system-model to not be able to resolve).

I think pit might work, as in first-and-last-letter-of-inspect ?

@ermo

ermo commented Aug 28, 2026

Copy link
Copy Markdown
Member Author

For ease of use, we might consider allowing pkg instead of package, given we already allow repo instead of repository?

What is your thinking on potentially allowing both package and pkg as well as repo and repository, while only showing one of each in help?

@livingsilver94

Copy link
Copy Markdown
Member

The moss package inspect alias (pin) might need to change, as the plan is to add an actual moss package pin command that saves a package in a default highest-priority cobble repo and keeps it there until the user removes it (which will typically happen when it causes the system-model to not be able to resolve).

Not a problem, I'll do that. But I want to highlight that a pin alias and a pin sub-subcommand wouldn't conflict with each other, assuming my algorithm for expanding aliases will be accepted. Granted, that'd be confusing for users.

For ease of use, we might consider allowing pkg instead of package, given we already allow repo instead of repository?

Yes please 😄

What is your thinking on potentially allowing both package and pkg as well as repo and repository, while only showing one of each in help?

I think I could just add a non-visible alias from clap_derive for that but to be honest, I don't think users will type unshortented "repository" or "package" unless forced to, as it is currently the case with "package".

@ermo

ermo commented Aug 28, 2026

Copy link
Copy Markdown
Member Author

If we make moss help show pkg and repo (while also allowing package and repository respectively) I think that'd be the nicest?

@livingsilver94
livingsilver94 force-pushed the ermo/task/moss-refactor-cli-approach branch from 331a69d to ca00901 Compare August 29, 2026 11:52
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 this pull request may close these issues.

moss: Unexpected command line parsing behaviour moss: Discuss a CLI

2 participants