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

limit possible values for parameters + required vs optional parameters #620

Closed
jeroenjacobs79 opened this issue Apr 16, 2017 · 6 comments
Closed
Labels
kind/feature describes a code enhancement / feature request

Comments

@jeroenjacobs79
Copy link

Hi,

I'm going to be honest, I'm a newbie at Go development and I mostly used Python + its argparse module for my commandline tools.

I've been going through the documentation, but I'm struggling with a few concepts:

  • How can I limit a certain commandline parameter to certain values? Eg: I have a commandline parameter "--type" which can only accept the following values: picture,sound or video. so "--type=video" would be valid, but "--type=program" will not. Is there a way to specify these constraints? Python's argparse module can solve this with the "choices" option.

  • How can I dictate a certain commandline should always be specified? Eg: "--type" should always be specified, with a value.

@jszwedko
Copy link
Contributor

Hi @jeroenjacobs1205!

  • Restricting flag options is not directly supported by this library currently, but is achievable via the exposed GenericFlag interface (declaring a struct implementing the GenericFlag interface that validates the value during the .Set() operation).
  • Required flags have been the topic of much discussion, but are also not currently directly supported by the library (see Required Flags #85 for more) . You can achieve similar results by validating that the flags are set after parsing using Context.IsSet..

Thank you for your interest! Just let me know if any of this is unclear.

I'll mark this as an enhancement with regard to the flag value restriction.

@jszwedko jszwedko added the kind/feature describes a code enhancement / feature request label Apr 18, 2017
@coilysiren
Copy link
Member

Given that this is from last year, I think I'm comfortable closing it 🙂 feel free to re-open / open a new issue / comment in support if there's still interest here!

@abdennour
Copy link

/reopen /open /re-open

@rliebz
Copy link
Member

rliebz commented Jul 24, 2021

@abdennour I re-opened and pinned #1154 (so it won't go stale), let me know if there's anything from this issue that warrants re-opening in addition.

@abdennour
Copy link

Thank you @rliebz ! should this answer #602 (comment) cover this issue ?

@rliebz
Copy link
Member

rliebz commented Jan 21, 2022

I think so, seems pretty straightforward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature describes a code enhancement / feature request
Projects
None yet
Development

No branches or pull requests

5 participants