Allow suppression of auto-created 'no-' flags for boolean options

[mbrgm]

The name of my option is --all. But I do not want the usage instructions to include a --no-all flag, as this is already the default behaviour.

https://github.com/erikhuda/thor/blob/d634d240bdc0462fe677031e1dc6ed656e54f27e/lib/thor/parser/option.rb#L89 already excludes the automatically inverted flag when the option name is 'force'. Maybe one could simply turn this into a metadata option (and include 'force' in some kind of blacklist for auto-inversed options).

Feature: Automatically created '--no-' options can be suppressed
  As a developer
  I want to be able to suppress the automatically created '--no-' flag for boolean options
  In order to remove them from the usage description

  Scenario: Automatically created '--no-' flag is suppressed explicitely
    When I create an option `:foo`
    And I set the option's `:type` to `:boolean`
    And I supply a metadata key `:auto_inversion` with a value of `false`
    Then the usage instructions of the command should not include a '--no-foo' flag

  Scenario: Automatically created '--no-' flag is requested explicitely
    When I create an option `:foo`
    And I set the option's `:type` to `:boolean`
    And I supply a metadata key `:auto_inversion` with a value of `true`
    Then the usage instructions of the command should include a '--no-foo' flag

  Scenario: Automatically created '--no-' flag is created by default
    When I create an option `:foo`
    And I set the option's `:type` to `:boolean`
    Then the usage instructions of the command should include a '--no-foo' flag

[afeld]

I would take it a step further: for any boolean option that isn't :required, only include the flag that is the inversion of the default.

[maxlinc]

I generally agree with @afeld, though there may be times that you do want the inverted flag but with a custom name.

Sometimes it might just be grammer. I'd rather have --not-verbose than --no-verbose (if I was going to use an inverted flag at all).

A better example where a custom name may clarify behavior: --auto-accept/--auto-reject (where omitting either flag might mean to prompt for a decision).

[ddarbyson]

@afeld agreed. Have you found any way to acheive this?

[afeld]

@ddarbyson I hadn't, and typed out a response saying so...but figured "what the hell", so took a couple passes at it last night (who needs sleep anyway??) Would love feedback on the PRs linked above.

[ddarbyson]

@afeld I tried your patch, works just fine. I ended up using it in the following fashion to have cleaner command line usage information when calling --help

    method_option '--no-remove', :type => :boolean, :desc => 'Do not remove contents before clone', :default => false
    method_option '--no-shallow', :type => :boolean, :desc => 'Do not truncate history during clone', :default => false

Then somewhere below, always default to 'false' unless --no-shallow is passed as a 'true' option

# this will always run by default as specified by method_option :default => false
unless option['no-shallow']
  ...
end

...it's backwards, but the only way to get around the overly verbose usage information for this type of scenario. Would be nice to see a method_option like :type => :no_switch or similar to work around all the extra steps.

[ezekg]

When is this going to get pushed out? I'm currently monkey patching the above fix for Thor::Option, but it would be great if we could push out a quick 0.19.2 soon to include this. I just removed the entire no-<opt> line, since it's really not needed for most cases. I would say add an option like :reverse_alias => true or something to explicitly state that you want a reverse bool.

[rafaelfranca]

We can't change the default behavior right now but we can in a future version, so I think the best thing to do right now is to add an option to disable the reverse option. Anyone want to take a stab on implementing it?

[waldman]

So... Was this implemented?

[xjunior]

@rafaelfranca @waldman Opened this to allow the suppression of the inverse flags: #733 I hope this get's merged

[BogdanIrimie]

Would love to see this!

[galevsky]

Is there any chance to see this #733 merged soon?