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

ArgEnum support hidden attribute #2756

Closed
2 tasks done
ModProg opened this issue Sep 7, 2021 · 7 comments · Fixed by #2758 or #2762
Closed
2 tasks done

ArgEnum support hidden attribute #2756

ModProg opened this issue Sep 7, 2021 · 7 comments · Fixed by #2758 or #2762
Milestone

Comments

@ModProg
Copy link
Contributor

ModProg commented Sep 7, 2021

Please complete the following tasks

  • I have searched the discussions
  • I have searched the existing issues

Clap Version

master

Describe your use case

I want to hide one value in an ArgEnum from for example [possible values: GitHub, Test]

Describe the solution you'd like

I would like to write this, and only have GitHub show up:

#[derive(ArgEnum)]
#[clap(rename_all = "pascal_case")]
enum CodeProviders {
    GitHub,
    #[clap(hidden(true))]
    Test,
}

Alternatives, if applicable

No response

Additional Context

No response

@pksunkara
Copy link
Member

Hmm.. can probably be implemented something similar to #2733. But looking at all these issues, do we need an ArgValue builder?

@ModProg
Copy link
Contributor Author

ModProg commented Sep 7, 2021

Hmm.. can probably be implemented something similar to #2733. But looking at all these issues, do we need an ArgValue builder?

I thought this could be implemented by just omitting it from the possible_values function, but that is used for validation as well if I understand your answer correctly?

@pksunkara
Copy link
Member

but that is used for validation as well

Yup, try the skip attribute on that value and try to use that value. It will lead to error.

@epage
Copy link
Member

epage commented Sep 7, 2021

I've been considering some related API problems and I was wondering if we should have an ArgValue that includes

  • Name
  • About
  • Hidden
  • Completion Hint
  • etc

We'd then change the signature for possible_values to

fn possible_values(values: impl Iterator<Item=impl Into<ArgValue>>)

where impl From<&str> for ArgValue sets the name.

  • We currently accept a slice but just to treat it as an iterator, so we can generalize to an iterator
  • Using Into<ArgValue> keeps the API simple for the common case while allowing for the complex cases
  • We'd be able to stop ballooning the API for each case (hints, about, names, etc)
    • For the singular cases, we could still have the individual functions

@pksunkara
Copy link
Member

Design looks good to me.

@epage
Copy link
Member

epage commented Sep 7, 2021

This would be a breaking change, technically. Should we tag with 3.0?

Oh, and it should be IntoIterator and not Iterator

@ModProg
Copy link
Contributor Author

ModProg commented Sep 7, 2021

I experimented in #2758 with something very similar, I would "upgrade" that to the proposed implementation.

@pksunkara pksunkara added this to the 3.0 milestone Sep 7, 2021
This was referenced Sep 7, 2021
@epage epage mentioned this issue Dec 6, 2021
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants