v3 MutuallyExclusive flags are not included in help text about cli HOT 7 CLOSED

Yes I think the latter approach of adding a Category field to the group is better.

from cli.

@joshfrench This feature hasnt been implemented yet. You are welcome to submit a PR. The changes would be primarily in the template.go file which has the template to render help text.

from cli.

Just getting around to this...

The basic case is straightforward, but once you account for flag categories I can see at least two approaches. The first doesn't discriminate between mutex and regular flags:

cmd := &cli.Command{
        Name: "test",
        MutuallyExclusiveFlags: []cli.MutuallyExclusiveFlags{{
            Flags: [][]cli.Flag{
                {
                    &cli.BoolFlag{
                        Name:  "b1",
                        Category: "one",
                    },
                },
                {
                    &cli.BoolFlag{
                        Name:  "b2",
                        Category: "two",
                    },
                },
            },
        },
        },
    }

GLOBAL OPTIONS:
   one

   --b1

  two

  --b2

This is flexible but doesn't quite track with my mental model of how mutex flags are meant to be used. The second approach would treat each mutex group as its own implicit category:

cmd := &cli.Command{
        Name: "test",
        Flags: []cli.Flag{
            &cli.StringFlag{
                    Name: "s1",
                    Category: "one",
            }
        },
        MutuallyExclusiveFlags: []cli.MutuallyExclusiveFlags{{
            Flags: [][]cli.Flag{
                {
                    &cli.BoolFlag{
                        Name:  "b1",
                    },
                },
                {
                    &cli.BoolFlag{
                        Name:  "b1",
                    },
                },
            },
        },
        },
    }

GLOBAL OPTIONS:
   one

   --s1

  ???

  --b1 | --b2

This approach is more prescriptive, but is closer to how I would expect things to work. Additionally:

• It suggests each flag group might benefit from a Name field.
• It does not address what happens if a mutex flag also sets a category, or if/how a user would be prevented from doing so.
• The exact formatting of mutex flags needs some thought; with sibling groups and default values it might become unwieldy: --string1 value | [ --bool1 (default: true) | --bool2 (default: false) ] | ...

Thoughts before I dive into category handling? I think I'm inclined to go with option 1 and leave it up to the user to categorize mutex flags how they wish:

cmd := &cli.Command{
        Name: "test",
        MutuallyExclusiveFlags: []cli.MutuallyExclusiveFlags{{
            Flags: [][]cli.Flag{
                {
                    &cli.BoolFlag{
                        Name:  "b1",
                        Category: "one",
                    },
                },
                {
                    &cli.BoolFlag{
                        Name:  "b2",
                        Category: "one",
                    },
                    &cli.BoolFlag{
                        Name:  "b3",
                        Category: "i know what i'm doing",
                    },
                },
            },
        },
        },
    }

from cli.

@joshfrench Yes option 1 would be good to provide maximum flexibility. But also we can have a check that all the mutex flags should be in the same category. It doesnt make sense to have these flag groups across multiple categories.

from cli.

@dearchap Is there a better place for that check than the MutuallyExclusiveFlags.check method? That seems aimed at catching user error, not cli developer error.

from cli.

Some alternatives to treating it as an error:

• Just coerce all the flags in a group to the first (or last?) category discovered within that group.
• Add a Category field to the group; ignore any Category set on flags within the group.

The latter strikes me as both easiest to implement and to understand as an end-user.

from cli.

PR updated! I did add a SetCategory() method to allow mutex groups to propagate their category downward to the flags within the group, which is triggering a docs warning -- I'll wait for a review before doing anything else. Thanks!

from cli.