murarth / gumdrop

Rust option parser with custom derive support

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

tuples

fretn opened this issue · comments

commented

Is there a possibility to support something like this:

    #[derive(Debug, Default, Options)]
    struct CreateOptions {
        #[options(no_short, help = "some parameter")]
        test_parameter: Vec<(String,String)>,
    }

so you can run commands like this:

./mybinary --test-parameter VARIABLE VALUE --test-parameter ANOTHERVARIABLE ANOTHERVALUE

That would be nice to have

This could be possible with an API change, but it would mean that option types would need to implement some custom trait (which would report how many parameters they expect to receive and then process each one). Presently, option types only need to implement FromStr and I rather like the simplicity of that. Couldn't you implement, as a workaround, something like this:

./foo --option KEY=VALUE
commented

Yes thats how I do it now, But I don’t like it :P

Actually, it occurs to me now that a custom trait isn't strictly necessary to implement this. The code generation could simply special case tuple-type arguments. It's already treating Option and Vec arguments as special cases, so I suppose it may as well handle tuples, too.

I'll get started on an implementation.

commented

That’s good news :)

@fretn: I've pushed the implementation.

commented

that's great ! any idea when it will arrive at crates.io ? (I'm new to this)

(it works btw, thank you very much !)

commented

I found one small issue: the --help output isn't correct yet for these tuples

Usage: ./target/debug/rsmodules [OPTIONS] [ARGUMENTS]

  -h, --help                 print help message
  --prepend-path PREPEND-PATH
                             prepend a path to a variable
  --append-path APPEND-PATH  append a path to a variable
  --setenv SETENV            set a variable
  --getenv GETENV            get a variable

--prepend-path, --append-path and --setenv are tuples of two Strings, maybe they can print:

--prepend-path VAL1 VAL2 (depending on the amount of items in the tuple)

You're right. The default meta string should be more accurate, though it won't be pretty. So, for tuple options, you should probably set the meta value explicitly. e.g.:

#[options(meta = "KEY VALUE")]
vars: Vec<(String, String)>,

Just pushed a commit for better default meta strings.

commented

looks good, nice work !