single purpose help vs complex help

[werelord]

I'm liking the project so far, but trying to figure out the context for help information with regards to the single purpose script vs the complex script referenced here

In the single purpose script, help is handled by opt.Bool("help", ... ) and if opt.Called("help") { fmt.Println(opt.Help() }

In the complex script, help is defined by opt.HelpCommand("help", ... ), handled within the Dispatch() call, returning ErrHelpCalled.

I just want to verify that this is correct; that these two methods of handling help are essentially exclusive (shouldn't be mixed). To me, it seems inconsistent having two different methods for handling help depending on the complexity; could help be handled within parse() returning ErrHelpCalled to make things more consistent?

Just a thought..

[DavidGamba]

Correct, the two methods are exclusive and aren't meant to be mixed.

I recall having considered handling the help on the parse call but decided against it. I need to look deeper as to the rationale of why and document it in the code.

When I created this library I wanted something very flexible that would allow me to create any kind of tool without being forced into a workflow.
The more I use the library the more certain patterns emerge in all my tools that would become convenient to codify.

WDYT of having a script that has a help command even though it has no other commands? Seems like the help output is not overly intrusive so it might make sense to get rid of having the help as a boolean call in the documentation.
Getting rid of opt.Help() doesn't seem necessary though so it seems like mostly a documentation change to align people into how to use the library.

[DavidGamba]

To add more info on why keeping opt.Help() is important, I just created a command where I want the argument to be an argument, not an option:

func GetProjectIDCMD(parent *getoptions.GetOpt) *getoptions.GetOpt {
	opt := parent.NewCommand("get-project-id", "Gets the project ID from the project Name")
	opt.SetCommandFn(GetProjectIDRun)
	opt.Bool("n", false, opt.Description("Don't print trailing newline"))
	opt.HelpSynopsisArgs("<project_name>")
	return opt
}

Calling the help looks like this:

$ ibuild gcp  get-project-id  help
NAME:
    ibuild gcp get-project-id - Gets the project ID from the project Name

SYNOPSIS:
    ibuild gcp get-project-id [--dry-run] [--help|-?] [-n] [--quiet]
                              <project_name>

OPTIONS:
    --dry-run    (default: false)

    --help|-?    (default: false)

    -n           Don't print trailing newline (default: false)

    --quiet      (default: false)

Now, if the user doesn't provide an argument, I want a helpful error:

$ ibuild gcp  get-project-id  
ERROR: missing <project_name>
SYNOPSIS:
    ibuild gcp get-project-id [--dry-run] [--help|-?] [-n] [--quiet]
                              <project_name>

Which I accomplish with:

	if len(args) < 1 {
		fmt.Fprintf(os.Stderr, "ERROR: missing <project_name>\n")
		fmt.Fprintf(os.Stderr, "%s", opt.Help(getoptions.HelpSynopsis))
		return getoptions.ErrorHelpCalled
	}
	project := args[0]

And in main, dispatch knows the error has been handled:

	err = opt.Dispatch(ctx, remaining)
	if err != nil {
		if errors.Is(err, getoptions.ErrorHelpCalled) {
			return 1
		}