Replies: 7 comments 6 replies
-
|
Problems:
Proposal: Implement a completion-specialized parser using a modularized lexer to centralize completion logic This is spelled out in #3166 and builds on #2915 Transition: |
Beta Was this translation helpful? Give feedback.
-
|
Problems: Lex using custom tokens
Proposal: Accept a This is spelled out in #1210 (comment) and builds on #2915 A default policy is probably good enough as the weight will likely be fairly small (low impact) and this shouldn't affect many users (small scope). Transition: None, this will be an opt-in API for those that want to use it |
Beta Was this translation helpful? Give feedback.
-
|
Besides simplicity. one of the reasons I went with a |
Beta Was this translation helpful? Give feedback.
-
|
Problems:
Proposal: What if we designed a trait that encompassed fallback values, validation, help generation, etc and This is a bit more out there of an idea The trait would be something like pub trait ParserState {
/// Metadata consumed by `Self` (used to detect when a user adds metadata but forgets the `ParserState`)
fn metadata_ids(&self) -> &[TypeId] { [] }
/// Prepare any state needed for parsing
fn build_parser(&mut self, cmd: &Command) {}
/// Prepare any state needed for any operation (help, completions, etc)
fn build_full(&mut self, cmd: &Command) {}
/// Fill in an unspecified value
fn default(&self, cmd: &Command, arg: &Arg, matches: &ArgMatches) -> Result<Option<OsString>> { Ok(None) }
/// Report any invalid states
fn validate(&self, cmd: &Command, matches: &ArgMatches) -> Result<()> { Ok(()) }
/// Augment an arguments help output with additional information, like defaults, env variables and their values, etc
fn arg_hint(&self, cmd: &Command, arg: &Arg) -> Option<Hint> {}
}The intent would be that this could be used for
These would be The user would have objects that they can pub trait CommandData: Any + Debug + 'static {}
pub trait ArgData: Any + Debug + 'static {}
struct EnvVar {...}
impl ArgData for EnvVar {}
...
let cmd = clap::command!()
.push_parser(EnvParser::new())
.push_parser(DefaultParser::new())
.arg(clap::arg!(--input <PATH>).set(Default::new("-"))
.arg(clap::arg!(--secrets <SHHH>).set(EnvVar::new().hide_value_in_help(true))
Benefits
Concerns:
Transition: Once clap v4 removes Blockers:
|
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
@epage recommended leaving a comment here. From clap Discussion #4402 I wrote
I just wanted to share my use-case for a more extensible "required argument" logic. Committed here. |
Beta Was this translation helpful? Give feedback.
-
|
One thing that's always itched me with validators, is that they're before the parser. I'd wager a guess that in the typical usage (probably vastly underrepresented in discussions), it's something super simple, like "I want this number to be in a specific range". They don't need a full-blown validator structure or anything, just a simple predicate using already parsed values. Parsed using the default Otherwise, you will end up with complexity on par with logging frameworks, where it took me several days just to set up |
Beta Was this translation helpful? Give feedback.
-
Slight tweak: most of the validators happen on the raw value, rather than the parsed value We target some simple validation cases with As for the rest of the APIs, we've left them as-is rather than blocking the adoption of value parser on getting parsed values to work everywhere. Most of these more general APIs I'm talking about would be working with something more like |
Beta Was this translation helpful? Give feedback.
-
|
Problems:
Proposal: As discussed in #3405, Add An Action is called per-occurrence (so it gets all of the values per occurrence) Actions
When building the
If this is done before #2683, Internally, we'll store all of this in an Open questions:
Transition:
Blockers:
|
Beta Was this translation helpful? Give feedback.
-
|
Clap 3.2 introduced this system and we moved over to it in 4.0. atm we have a limited set of actions (Set, Append, SetTrue, SetFalse, Count, Help, Version)
#4687 requests distinguishing short/long help For custom actions, we would want to allow everything we support today, including
We might also want to expose what flag was matched as that would allow for a workaround for #815. As of this post, the blockers for custom actions were
|
Beta Was this translation helpful? Give feedback.
-
|
Problems:
Proposal: We create Traits for Usage and Help and make operations that rely on them generic with a default parameter (help and usage rendering, parsing, etc). These traits are configured via So by default, you get the auto-generated help. To hard code the help, you pass in a We could then explore giving more control over help generation by decoupling help generation from help rendering, see #2914. We can then refactor Open questions:
Random Notes:
Transition:
|
Beta Was this translation helpful? Give feedback.
-
Problem:
Proposal:The usual solution to this type of problem, just use Rust itself. Specifically: accept a function pointer as a predicate. Assuming we have a hypothetical
Challenges:The MapBest I can tell, anymap is unmaintained - there has been no commits for over a year. Perhaps it's worth getting in touch with tracing/tokio folks and asking about the status of |
Beta Was this translation helpful? Give feedback.
-
|
Hi, is there any crate recommended to get env working ? |
Beta Was this translation helpful? Give feedback.
-
The intention here is to open the field for brainstorming. A lot is going to be included in here, not to say that we have to solve all problems with one solution or solve all problems at once but so we keep our eyes open to the entire field so we can look for solutions we might not have others.
Response template:
Discussing this post itself:
Proposing a solution:
Goal: Can we refactor clap into a state where
Examples of requests we have today
clap_mangen, includingclap_mandoesn't show the right number of value names #3359clap_mandoesn't render optional values with[=<VALUE>]#3358clap_manshould respect the configured display order for args and subcommands #3362---long) #3309 for compatibility with gnu coreutilsversionorhelps behavior #3405We've also had requests like
Prior discussions
Design tools at our disposal
Considerations
--fooconflicting with--barmeans--barconflicts with--foo) but keeping the symmetry implied makes it easier to compose a CLI as the definition for one part doesn't need to know about the definition of anotherBox<dyn Validation>to be passed in to replace the default validation logic, we still have to have some kind of default validation logic that meets whatever criteria we set and this will need to be compiled and included in the binary)Risks:
Beta Was this translation helpful? Give feedback.
All reactions