Movement CLI: organization and usability

[mzabaluev]

• Consider maintaining the CLI "front" binary as a crate hosted in movement.

  • aptos-cli is also a library that can be linked from outside the crate.
  • Any Movement-specific add-ons don't need to be in the aptos-core delta.
  • The current approach of hacking and renaming aptos-cli increases the delta with upstream. We can't get around the need for all hacking (branding in output messages etc.), but the crate name and the API don't need to be changed with the approach suggested here.
  • It will also be simpler for external developers and integrators to learn where the CLI is at.

• Review any additions we need to make to the CLI for usability and consistency.

[l-monninger]

So, what are all the functions this CLI should perform? What are its top level command paths?

In the past, we had this CLI under development for M1: https://github.com/movementlabsxyz/M1/tree/main/movement-sdk/clis/movement/src

I had identified aptos and sui domain logic, downloading versioned resources, and running network services as the primary functions of CLI users. Thus, the first paths were aptos, sui, manage (for downloads), and ctl.

[mzabaluev]

So, what are all the functions this CLI should perform? What are its top level command paths?

Currently all commands are inherited from aptos CLI.

In the past, we had this CLI under development for M1: https://github.com/movementlabsxyz/M1/tree/main/movement-sdk/clis/movement/src

I had identified aptos and sui domain logic, downloading versioned resources, and running network services as the primary functions of CLI users. Thus, the first paths were aptos, sui, manage (for downloads), and ctl.

Should we restore some of these and move the current command tree to the aptos subcommand?

[l-monninger]

Before we get to the movement CLI though, what do you think about just speccing out @0xmovses proposal to do a Clap CLI for every service w.r.t to #385 ?

Again, I think #340 could help us in some interesting ways here.

[0xmovses]

I'll gather some info and write up an issue for us to review, or perhaps this is RFC worthy..

[mzabaluev]

#385 discusses the command-line options of service binaries, so clapping out of these binaries should be also connected to that.

I don't think it would be useful in general to conflate inter-component command queues used in actor reworks discussed in #340 with user-facing commands.