Parsing option argument from "k:v,k:v,..." into HashMap<String, String>

[fritzrehde]

Is it possible to parse an argument to an optional like --option "key:value,key2:value2" (or any other format that works, like -o "key=val" -o "key=val") into HashMap<String, String> with clap derive (automatically)?

[epage]

At the moment, this is not supported.

We would need to design-in custom container support and work out specifically for HashMap how to deal with mapping multiple generic parameters (HashMap<K, V>) with (K, V).

[epage]

https://github.com/clap-rs/clap/blob/master/examples/typed-derive.rs is an example of parsing key-value pairs. That code is sufficient to support -o key=val -o key=val. To support --option key:value,key2:value2, you would just need to set value_delimiter = ','

[fritzrehde]

Thanks, this works very well! It was easy to get a Vec<String, String> from clap and then parse that into HashMap<String, String> manually.

[fritzrehde]

Any updates on this? Will parsing directly into a HashMap be supported at some point? Currently, I get

keybindings: Option<Vec<(String, Vec<String>)>>

directly from clap derive, and then just have to convert that to a hashmap with something like

keybindings.and_then(|vec| Some(vec.into_iter().collect()))

I am guessing implementing something like that into clap would be much more difficult, otherwise it would probably be implemented already.

[epage]

No updates. If you are wanting this to move forward, the first step would be creating an issue. We also have focus areas and work outside of those focus areas require more effort from issue authors / contributors to keep them moving forward.

[cw-1988]

I know, necropost. but i would be happy if i could have a parser function that is also give self/the struct so we can populate current incompatible fields (the hashmap in this case) ourselves. i don't know what you do internally when you come across a field type you can't parse into. maybe you just skip it, print a warning or even panic, but a suppressable warning skip would be great, so we can then populate the field ourselves. because i really want to avoid manual field to field mapping from a CliArgs struct to a Settings struct... :-)