-
Notifications
You must be signed in to change notification settings - Fork 553
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
Allow boolean flags without automatically creating a --no-option
version
#553
Comments
Hey Will, I think I would agree with you on this one. It feels that thor is assuming too much for its own good. If you consider Ruby standard method_option "[no-]list", type: :boolean
# or
method_option :list, type: boolean, negate: true |
A related issue is how to provide an alias for the negated boolean option that is separate from the positive boolean option? For example, if the my CLI is uses this option:
What is the best way to provide an alias for the negation? As a work-around, I've created opposite booleans, that are mutually exclusive. Eg:
|
I hit this today. I have a case where I want to delete all of something. It doesn't make sense to delete not-all of something:
|
Duplicated of #417 |
Context: I'm working on a command that needs a boolean flag, we'll call it
--list
. If this flag is provided, I want to display a list of items. Otherwise, the list will not be displayed. Currently, if I add this option like so:Thor automatically creates a
--no-list
option, which I don't need and is confusing in the help output:This is due to this line: https://github.com/erikhuda/thor/blob/db16e19ad4bc797c580a2646ab54606fd0fd294f/lib/thor/parser/option.rb#L91
Thor should be able to create a boolean flag like this with a default value (false in this case) and not create the negation of the option.
Alternatively, perhaps this is just bad style? Should I be implementing
list
as a subcommand? Any thoughts are appreciated!The text was updated successfully, but these errors were encountered: