[Discussion] expand features of Inheritable

[myOmikron]

Follow-Up issue for #17.

I divide this up into 2 sections, that stand for themselves, but also could be combined.

1. Exclude main parser

As there are many cases, where you want the main parser not to have the options its successors inherit.

Quick example:

I'm building a application, that can monitor a linux server.
Therefore my application looks like this:

~> ./linux --help
usage: Linux Plugin <cmd> [--help] [--version] [--generate-description] 

Linux Plugin

available commands:
  load                    Checks the load of a target
  uptime                  Checks the uptime of the target
  swap                    Checks the swap of the target
  memory                  Checks the memory of the target

~> ./linux load
usage: Checks the load of a target

Checks the load of a target

options:
  --help, -h                                 show this help message

snmp options:
  --snmp-version SNMP-VERSION                SNMP Version. One of 1, 2c, 3
  --snmp-community SNMP-COMMUNITY            Community of SNMP. Only applies for SNMP v2c
  --snmp-user SNMP-USER                      Username to authenticate with. Only applies for SNMP v3
  --snmp-security-level SNMP-SECURITY-LEVEL  Security level of SNMP messages. One of noAuthNoPriv, authNoPriv, authP
                                             riv. Only applies for SNMP v3
  --snmp-auth-protocol SNMP-AUTH-PROTOCOL    Protocol for authentication. One of sha, md5. Only applies for SNMP v3.
                                              Defaults to sha
  --snmp-auth-pass SNMP-AUTH-PASS            Passphrase for authentication. Only applies for SNMP v3
  --snmp-priv-protocol SNMP-PRIV-PROTOCOL    Protocol for privacy. One of aes, des. Only applies for SNMP v3. Defaul
                                             ts to aes
  --snmp-priv-pass SNMP-PRIV-PASS            Passphrase for privacy. Only applies for SNMP v3
  --snmp-timeout SNMP-TIMEOUT                Timeout of the SNMP query in seconds. Defaults to 2.0
  --snmp-port SNMP-PORT                      Port of the SNMP daemon. Defaults to 161
  --snmp-protocol SNMP-PROTOCOL              Protocol used for transport. One of udp, tcp. Defaults to udp

plugin options:
  --hostname HOSTNAME, -H HOSTNAME           The hostname to query.
  --warning WARNING                          Load values that determine if warning should be set. Format: load1,load
                                             5,load15
  --critical CRITICAL                        Load values that determine if critical should be set. Format: load1,loa

As you can see, the snmp options section contains all settings to configure snmp in the application. This will be identical throughout all subcommands. But it makes no sense to add them onto the main parser. I could imagine, there are many use-cases, where you won't wanna have the options on the main parser.

2. Let users define the parsers they want to set the option to

In the current version (v1.8.1) it is only possible to inherit options to parsers defined below them. In my opinion, this approach is too much limiting and not really intuitive for users, as there's some kind of "magic" happening that decides to which parser the option gets attached to.

This behavior rises another problem:
It's currently not possible to have two options with the Inheritable flag set, inherited by mutually exclusive parsers.

Example:

• ab should be registered on aParser and bParser.
• bc should be registered on bParser and cParser

parser := argparse.NewParser("", "", nil)
ab := parser.String("", "ab", &argparse.Option{Inheritable: true})
a := parser.AddCommand("a", "", nil)
bc := parser.String("", "bc", &argparse.Option{Inheritable: true})
b := parser.AddCommand("b", "", nil)
c := parser.AddCommand("c", "", nil)

ab would be also registered on cParser.

I think the prettiest solution would be to be able to define explicitly where an option should be attached to.

parser := argparse.NewParser("", "", nil)
a := parser.AddCommand("a", "", nil)
b := parser.AddCommand("b", "", nil)
c := parser.AddCommand("c", "", nil)

ab := parser.String("", "ab", &argparse.Option{
    Parsers: []*argparse.Parser{a, b},
})
bc := parser.String("", "bc", &argparse.Option{
    Parsers: []*argparse.Parser{b, c},
})

[hellflame]

Now I can get the point, mainly to share an argument freely in many parsers. I guess we can call it share (or something else) more than inherit, it should be easier to use than inherit.
I can see the beauty there.

[hellflame]

I've made some changes for it on master. If there's no more quest, I'll publish this to next version soon.

[myOmikron]

Two comments:
1.: I discussed the naming with a few mates, we came to the conclusion that BindParsers could be misleading. How about RegisterOn, AddTo or AttachTo?

2.: How do we attach the option to the main parser? Does this happen implicit because we create the option on the main parser or should we require the user to add the main parser to the list of BindParsers?

parser := argparse.NewParser("", "", nil)
a := parser.AddCommand("a", "", nil)

a := parser.String("", "ab", &argparse.Option{
    BindParsers: []*argparse.Parser{a, parser},
})

Personally I would prefer the latter solution.

[hellflame]

The name BindParsers actually is a name to discuss. For the name BindParsers, which is the meaning to specify it's parser, and tell user that you've chosen to bind given parsers for this argument, so it won't be registered on the main parser. AddTo, AttachTo may have the meaning to bind more parsers. RegisterOn is quite similar to BindParsers, I guess BindParsers is semantic enough.

As for the second comment, that's right, you need to make the parser as one element of the BindParsers. This is much simpler.

[myOmikron]

So it's irrelevant, where the option is created?

parser := argparse.NewParser("", "", nil)
aParser := parser.AddCommand("a", "", nil)

test := parser.String("", "test", &argparse.Option{
    BindParsers: []*argparse.Parser{aParser, parser},
})
test2 := aParser.String("", "test2", &argparse.Option{
    BindParsers: []*argparse.Parser{aParser, parser},
})

Would result in both options attached to both parser?

[hellflame]

The option should be created after NewParser or AddCommand, so the parser can be referred to.
Of course, whether you can successfully bind an option to the given parser list is another thing. Like you can't bind multiple same entries to the same parser. []*argparse.Parser{parser, parser} will absolutely fail, and if the parser has already registered an argument with full name test, it will cause a conflict entry panic.

---

test := parser.String("", "test", &argparse.Option{
    BindParsers: []*argparse.Parser{aParser, parser},
})
test2 := aParser.String("", "test2", &argparse.Option{
    BindParsers: []*argparse.Parser{aParser, parser},
})

Yes, test & test2 will be bond to aParser (sub parser) & parser (main parser). There should be no problem.

[myOmikron]

So this sounds fine for me. Feel free to close this issue.

[hellflame]

Thank for the idea. And the feature is published on v1.9.0