Skip to content
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

TP 201: Project 3 CLI Requirement #385

Open
parthik19 opened this issue Feb 25, 2021 · 1 comment
Open

TP 201: Project 3 CLI Requirement #385

parthik19 opened this issue Feb 25, 2021 · 1 comment
Labels
type/enhancement New feature or request

Comments

@parthik19
Copy link

Feature Request

In project 3 for TP 201, the specs say that the --addr field should show up last for kvs-client. I think this isn't the best design because it unnecessarily complicates the subcommands set get and rm by forcing us to append the --addr field to each of them. (see the reference solution). Instead, if placed at the beginning, it makes the parsing much less verbose and also more intuitive, since the --addr is a feature of the kvs-client as opposed to the specific command being executed.

Is your feature request related to a problem?

No.

Describe the feature you'd like

Change the requirements for project 3 to indicate that the --addr field should show up in the beginning of the command. In other words, the specs should look something like this:

USAGE:
    kvs-client [OPTIONS] <SUBCOMMAND>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
        --addr <addr>     [default: 127.0.0.1:4000]

SUBCOMMANDS:
    get     
    help    Prints this message or the help of the given subcommand(s)
    rm      
    set     

Describe alternatives you've considered

There is no straightforward way (that I've come across in the past couple hours) that allows us to easily append a flag that applies to all subcommands at the very end.

@parthik19 parthik19 added the type/enhancement New feature or request label Feb 25, 2021
@mlodato517
Copy link

mlodato517 commented May 29, 2023

One alternative I found, which may be newer than this issue, is the global method which can also be set via derive attributes.

Example with clap
#[derive(Parser)]
#[command(version)]
struct Args {
    #[command(subcommand)]
    command: Command,

    #[clap(long, default_value = "127.0.0.1:4000", global = true)]
    addr: String,
}
#[derive(Subcommand)]
enum Command {
    Set { key: String, value: String },
    Get { key: String },
    Rm { key: String },
}

And here is an example from structopt.

It may or may not make sense to call this out in the tutorial. Additionally, if it is better CLI design (I am not an expert here) to move the option up, then I imagine the tutorial should specify that regardless of a "workaround" (i.e. global). But I can't speak confidently to that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants