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

[modular] User-driven values (defaults, env vars, implied values, etc) #4793

Open
epage opened this issue Mar 27, 2023 · 1 comment
Open
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing

Comments

@epage
Copy link
Member

epage commented Mar 27, 2023

With clap today, each value source needs to be hard coded, including

When new use cases arise, users either have to

It would help if clap had an API for users to provide their own systems for this. See also #3476.

Example unsupported use cases

default_value and default_missing_value are integral to Actions, so I'm thinking we leave those as built-in

Requirements

  • Know the source for existing relevant arg values
  • Able to set the source for value
  • Able to augment the help description of a specific argument with details
  • Ideally help uses with ValueSource precedence
  • Ideally leverage built-in Action behavior
  • Ideally not so unergonomic to be unuseful

Tools

  • Plugin API to allow storing arbitrary data on Command/Arg
  • Blanket impl of a trait for functions
  • Into to allow custom plugin data to be converted to the plugin type
@epage epage added C-enhancement Category: Raise on the bar on expectations A-parsing Area: Parser's logic and needs it changed somehow. S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing labels Mar 27, 2023
@epage
Copy link
Member Author

epage commented Mar 27, 2023

Idea

trait ValueSource {
    /// Fill in additional values
    fn fill_values(&self, cmd: &Command, values: &mut ...) {}
    /// 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> {}
}

Ideally, we allow a user to define a source on an Arg and automatically adapt it to be for the Command, imagine if:

struct Env {
    name: Str
}

struct CommandEnv {
    id: Id
    value: Env
}

impl From<(&'_ Arg, Env)> for CommandEnv {
    fn from(other: (&'_ Arg, Env)) -> Self {
        Self { id: other.0.get_id(), value: other.1 }
    }
}

epage added a commit to epage/clap that referenced this issue Mar 28, 2023
This has been implemented for 3 years without much traction for
finishing it up.

The subcommand use case can be worked around by creating `Command`s that
just include the relevant logic, very similar to the default subcommand
examples in `git` / `git-derive`.

Using this for flags is covered by clap-rs#4793.

Without `unstable-replace` being enabled, this still cut 5 KiB from
`cargo bloat --release --example git`.

Closes clap-rs#2011
epage added a commit to epage/clap that referenced this issue Mar 28, 2023
This has been implemented for 3 years without much traction for
finishing it up.

The subcommand use case can be worked around by creating `Command`s that
just include the relevant logic, very similar to the default subcommand
examples in `git` / `git-derive`.

Using this for flags is covered by clap-rs#4793.

Without `unstable-replace` being enabled, this still cut 5 KiB from
`cargo bloat --release --example git`.

Closes clap-rs#2836
Closes clap-rs#2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing
Projects
None yet
Development

No branches or pull requests

1 participant