Make `ockam project delete` (no args) interactive by asking the user to choose from a list of space and project names to delete (tuify)

[nazmulidris]

Current behavior

When a user runs ockam project delete without any arguments, currently they are shown an error & some help text is displayed asking them to provide the <SPACE_NAME> and <PROJECT_NAME>. Here's a screenshot of this.

Desired behavior

Instead of displaying this help text, change the behavior of this command so that it becomes interactive with the user. Note that this can only be allowed to happen if:

• the terminal is interactive, and,
• the --no-input or --quiet flags have not been passed, and,
• no arguments have been passed in to the command.

The user needs to be asked for 2 things: 1) one <SPACE_NAME> 2) one or more <PROJECT_NAME>

This what the user flow should look like in interactive mode. 1) Use the tuify crate's select_from_list() function to ask the user to select from a list of space names. They should be able to make a single selection. If there are none, then simply display a message saying that none exist (not an error) and exit.

2) Use the tuify crate's select_from_list() function to ask the user to select from a list of project names (for their given space name). They should be able to make a multiple selections.

3) Once the user has made their selection(s), display a confirmation prompt letting the user know that that a destructive operation is about to take place with the space name and project name(s) (belonging to that space) they have selected. Use select_from_list() to display this prompt. They should be able to make a single selection.

• If they have made no selections then exit by displaying a message to the user letting them know they did not make any selection. 4) If they choose "YES", then delete each selected project from the space, and display a success / failure message for each project that got deleted from the space.
• If an operation succeeds then use the ✅ emoji as a prefix for the message.
• And if it fails, then use the ⚠️ emoji as a prefix for the message.

The following is a video showing a generic user flow that shows the user experience when a user is asked to choose a from a list of "things". Then an action is performed on each "thing". Finally status information is reported for each action that is performed on each "thing". Please note that this flow is not specific to this issue. https://asciinema.org/a/612547

Implementation details

• Please use the functions select_multiple, and confirm_interactively in this file.

• Here's a similar PR to get some ideas from: https://github.com/build-trust/ockam/pull/6480

• You can learn more about how to use the select_from_list() in the tuify crate here. Here is an example that is very similar to the steps you might have to take for this issue.

• Here's a file you can look at to detect when a terminal is interactive or not.

• Here's a file you can look at to see where the ockam project delete command is implemented.

---

We love helping new contributors! ❤️ If you have questions or need help as you explore, please join us on Discord. If you're looking for other issues to contribute to, please checkout our good first issues.

[biesnecker]

Hi, I would be interested in taking this on. I'll start to poke at the code and see if I have any questions.

[nazmulidris]

@biesnecker That's awesome, this is all yours. Please let us know if you have any questions as you explore. You can also ask questions on the contributors discord https://discord.gg/RAbjRr3kds

[biesnecker]

I asked on Discord but will record here too:

Hi, I'm looking at https://github.com/build-trust/ockam/issues/6461, and running into an error when I try to make the space_name and project_name options optional in the delete command. The actual error I get is:

future cannot be sent between threads safely
future returned by `rpc` is not `Send`rustcClick for full compiler diagnostic
delete.rs(56, 6): opaque type is declared here
delete.rs(43, 12): this item depends on auto traits of the hidden type, but may also be registering the hidden type. This is not supported right now. You can try moving the opaque type and the item that actually registers a hidden type into a new submodule
delete.rs(49, 5): future is not `Send` as it awaits another future which is not `Send`
mod.rs(51, 62): required by a bound in `node_rpc`

I more or less understand what it's saying, but I don't understand how switching from String to Option<String> would cause it. miette::Result doesn't change. The example PR given (https://github.com/build-trust/ockam/pull/6480) uses local_cmd rather than node_rpc, which might be why it wasn't an issue in that one?

[Lumexralph]

If this issue is not yet done, please, can you assign it to me?

[nazmulidris]

@Lumexralph It is all yours! 👍🏽