-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Support for using ArgGroup as Enum with derive #2621
Comments
When I was implementing the #[derive(Clap)]
pub struct App{
#[clap(flatten)]
pub state_filter: Option<StateFilter>,
}
#[derive(Args)]
pub enum StateFilter {
/// Only running servers are returned
#[clap(long)]
Running,
/// Only exited servers are returned
#[clap(long)]
Exited,
/// Only restarting servers are returned
#[clap(long)]
Restarting,
} (with an attribute on the enum to override the group name) Though I hadn't considered
|
This would be lovely for my use case (an archive utility, where the operation modes are exclusive but otherwise share the same options, similar to |
You can workaround this by manually defining the arg group and adding the arguments to it. While its using structopt instead of clap-derive, the principle and calls are pretty much the same in this code of mine. |
The problem with argument groups and the struct equivalent is that you can't ask clap what option was specified, all you can do is check each individual option of the group for presence in the arguments. We're back to to arguments not really being parsed into something useful. With subcommands, clab directly talls you what subcommand was found in the arguments, as either an Enum or as the string ID of the subcommand. In both cases you can actually match on something instead of having an if-else chain or iteration simply to know which one it was |
I have a perfect use case for this right now: my app can accept a config file, or (perhaps if the config is very short) a string directly in the command line. For instance:
The config string is not designed to be parsed by the app; it's passed directly through to the output. I have no desire to parse it. Ideally, I'd write something like this:
|
Yes, its only a workaround to help keep people from being blocked and is not ideal. We are trying to focus on polishing up clap v3 before before working on new features. Once v3 is out (and maybe a little after as we do high priority work we postponed), we can look into this or mentoring someone who can look into this, |
I'd like to offer another example that I would like to support with this feature. It's slightly more complex than the existing one, so worth calling out explicitly I think. I have a tls configuration that requires three pem files, representing the root certificate, the application cert, and the application's private key. By convention, they all live in the same directory, as #[derive(clap::Args)]
enum Pems {
Dir {
#[clap(long)]
pem_dir: PathBuf,
}
Files {
#[clap(long)]
key: PathBuf,
#[clap(long)]
cert: PathBuf,
#[clap(long)]
root: PathBuf,
}
} or #[derive(clap::Args)]
enum Pems {
Dir(PemDir),
Files(PemFiles),
}
#[derive(clap::Args)]
struct PemDir {
#[clap(long)]
pem_dir: PathBuf,
}
#[derive(clap::Args)]
struct PemFiles {
#[clap(long)]
key: PathBuf,
#[clap(long)]
cert: PathBuf,
#[clap(long)]
root: PathBuf,
} |
For what it's worth, I thought I understood the clap "language" of modeling out commands and flags and naturally reached for this and it took me a while to realize (and find this issue) that it wasn't possible. I'm making do with the #[derive(Parser, Debug)]
#[clap(group = clap::ArgGroup::new("image-tag").multiple(false))]
pub struct ImageTag {
#[clap(long, group = "image-tag")]
existing: bool,
#[clap(long, group = "image-tag")]
new: bool,
#[clap(long, group = "image-tag")]
tag: Option<String>,
} versus something like: #[derive(Parser, Debug)]
pub enum ImageTag {
Existing,
New,
Tag(String)
} Just wanted to register my interest. Thanks for providing a workaround! |
Are there any plans to implement this yet, now that clap v3 has been out for a while? I did take a crack at it after I first commented here (about 9 months ago now...); I tried a couple different approaches, angling to adapt existing ArgGroup code to accept enum variants, but I kept running into flaws in my type model that made the whole thing fall apart. It didn't help that it was my first experience writing proc macro code, either, though I got impressively far considering. All that being said, if someone can come up with a sound design, I might be able to help with implementation. |
This is not a priority of mine. My focus is on binary size, compile times, and extensibility. If someone else wants to work on a design proposal and then do an implementation, they are free to do so. |
I have encountered a situation where supporting this would be extremely useful. Specifically I am wanting to provide different authentication methods for a service. The following is a rough sketch of how I was imagining such a feature: #[derive(Debug, Args)]
struct UserPassAuth {
#[clap(short, long)]
username: String,
#[clap(short, long)]
password: String,
}
#[derive(Debug, Args)]
struct TokenAuth {
#[clap(long)]
token: String,
}
#[derive(Debug, Default, MutuallyExclusiveArgs)]
enum AuthenticationMethod {
#[default]
Anonymous,
UserPass(UserPassAuth),
Token(TokenAuth),
} This isn't necessarily a priority in that argGroups do exist, and they can be made mutually exclusive through that mechanism, but this does significantly clean up the interface that you have to deal with externally. match authentication {
AuthenticationMethod::Anonymous => anonymous_login(),
AuthenticationMethod::UserPass(login_info) => login(login_info),
// ...
} I'm not nearly confident enough to take a stab at implementing it, but if there's guidance on how this might be correctly implemented I would be interested in having direction. |
I'd like to get to this during 4.x series. Some ground work I need to do in 4.0.0
|
@epage I see this is tagged with "e-help wanted". Is there anything specifically I can help with? I'm pretty interested in this. |
@klnusbaum a good introduction to the code base that I'm assuming you'll want anyways is #4574. If you want to take that, feel free to ask for more details in that issue. Note that this one is also tagged |
Correct me if I'm wrong, the feature that is being requested here would allow parsing mutually exclusive sets of flags into different variants of an enum, right? I really want to remove all the |
Yes, this would allow conflicts to be expressed in the type system |
Given build options (cargo workspace options, e.g. `-p my_crate`), the `upload` command will build before uploading, and given build or upload options `actvate` will build or upload before activating. These primary options are mutually exclusive, but may require nested ArgGroups in the future which are supposed to be supported, perhaps aided by clap-rs/clap#2621 if resolved. The current constraints and reuse of shared options is rather crude (see in particular UploadOptsWrapper). Introduces some technical debt with regards to server/client parity, which should be unified under the carol_core crate.
Given build options (cargo workspace options, e.g. `-p my_crate`), the `upload` command will build before uploading, and given build or upload options `actvate` will build or upload before activating. These primary options are mutually exclusive, but may require nested ArgGroups in the future which are supposed to be supported, perhaps aided by clap-rs/clap#2621 if resolved. The current constraints and reuse of shared options is rather crude (see in particular UploadOptsWrapper). Introduces some technical debt with regards to server/client parity, which should be unified under the carol_core crate.
Given build options (cargo workspace options, e.g. `-p my_crate`), the `upload` command will build before uploading, and given build or upload options `create` will build or upload before creating a machine. These primary options are mutually exclusive, but may require nested ArgGroups in the future which are supposed to be supported, perhaps aided by clap-rs/clap#2621 if resolved. The current constraints and reuse of shared options is rather crude (see in particular UploadOptsWrapper).
Given build options (cargo workspace options, e.g. `-p my_crate`), the `upload` command will build before uploading, and given build or upload options `create` will build or upload before creating a machine. These primary options are mutually exclusive, but may require nested ArgGroups in the future which are supposed to be supported, perhaps aided by clap-rs/clap#2621 if resolved. The current constraints and reuse of shared options is rather crude (see in particular UploadOptsWrapper).
Given build options (cargo workspace options, e.g. `-p my_crate`), the `upload` command will build before uploading, and given build or upload options `create` will build or upload before creating a machine. These primary options are mutually exclusive, but may require nested ArgGroups in the future which are supposed to be supported, perhaps aided by clap-rs/clap#2621 if resolved. The current constraints and reuse of shared options is rather crude (see in particular UploadOptsWrapper).
Given build options (cargo workspace options, e.g. `-p my_crate`), the `upload` command will build before uploading, and given build or upload options `create` will build or upload before creating a machine. These primary options are mutually exclusive, but may require nested ArgGroups in the future which are supposed to be supported, perhaps aided by clap-rs/clap#2621 if resolved. The current constraints and reuse of shared options is rather crude (see in particular UploadOptsWrapper).
Any updates on this? Is someone working on this? |
Not at this time |
## Description - modifies the `blob download` ux to make it clear, and properly enforce having either a ticket or arguments for a download - All arguments apply to both ticket and hash but with different constrains. In the case of the ticket options can be used to override/remove ticket parts - makes sure failures still report the help text ## Notes & open questions ### Sample output: This would previously only show an error ``` > blob download Download data to the running node's database and provide it Usage: blob download <COMMAND> Commands: ticket Use a blob ticket to download the data hash Supply the content and node-addressing information directly to perform a download help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see more with '--help') ``` ### Calling commands: #### With a ticket: ``` > blob download ticket blobedjoqrkky753mdwphqrxbr2wjzkizv4hkb5s5ovav73c2zfuaja7aaibaiah6aaaahcfoaiaaaaaaaaaaaaaaaaaaaaaaaabyvlqcz2d7d7ouqasz36mapwfxqf2dx3zznb25nx32phl7kbgum23wtegaa ``` #### With args: ``` > blob download hash bafkr4ibzusj4ulmrhrbymsgklwlcencx63jwcurmoimjhk4mutqdsqhnqa --node 2luekswh7o3a5tz4enymovsoksgnpb2qpmxlvifp6ywwjnacihya --derp-region 1 ``` Both NOTE: Adding this a a subcommand is a consequence of clap-rs/clap#2621 ## Change checklist - [x] Self-review. - [x] Documentation updates if relevant. - [ ] Tests if relevant.
When clap-rs/clap#2621 is resolved, we will be able to derive a set of mutually exclusive boolean flags from an enum in a struct that derives clap::Parser.
When clap-rs/clap#2621 is resolved, we will be able to derive a set of mutually exclusive boolean flags from an enum in a struct that derives clap::Parser.
Maintainer's notes
Args
on an enum would create aArgGroup::new("T")::multiple(false)
#[group(...)]
(split out as Implement more derive attributes for ArgGroup #4574)Args::group_id
, flattening struct variants would use the Variant.Arg::id
set toVariant::field
, see Traefik-style `.` separated flag categories #4699.clap_derive
so we can share code between structs and enumsArgs
struct #3165Blocked on #3165 as that will lay some of the initial groundwork and #4211 to provide a fallback mechanismRelated
Please complete the following tasks
Clap Version
3.0.0-beta.2
Describe your use case
I have multiple filters of witch only one can be set (
--running
,--exited
,--restarting
,...).Describe the solution you'd like
I would like something with this usage:
Resulting in:
Alternatives, if applicable
I could use an arggroup for this currently, but I would still need to check each boolean separately and could not just easily (and readable)
match
it.Additional Context
No response
The text was updated successfully, but these errors were encountered: