What's Changed

New Copier type permits reuse of flag.Value objects as defaults for multiple parameters.

Full Changelog: v2.2.2...v2.3.0

This release adds support for subcommand-implementing functions whose parameter lists end in ...string as an alternative to []string.

It also adds support for flag.Value-typed parameters.

It also adds support for multiple leading hyphens in the Param.Name field; i.e., you can write "-verbose" or "--verbose" (or even "---verbose") and it will mean the same thing: a flag named verbose, which at runtime will match a command-line option named -verbose or --verbose (per the behavior of Go's standard flag package).

This release adds "external subcommands" and the Check and CheckMap functions, and expands the semantics of the Commands function.

External subcommands

In a call to Run(ctx, cmd, args), args[0] is the name of a subcommand to execute from the cmd.Subcmds map. If name does not appear in the map, the result is normally an UnknownSubcmdErr error.

But with this change, if cmd implements the Prefixer interface in addition to Cmd, then cmd.Prefix is called to get a prefix, and then an executable named prefixname is sought in $PATH. If found, it's executed with the remaining args as arguments, and a JSON representation of cmd in the environment variable SUBCMD_ENV (which can be parsed with the new function ParseEnv).

This feature is patterned after command-line tools such as git, which has some built-in subcommands of its own, but which can be extended by putting an executable named git-foo in $PATH (to create subcommand foo).

Check and CheckMap

These new functions perform various runtime type-safety checks on a Subcmd and a Map, respectively.

Commands

The Command function previously required arguments in groups of four:

• subcommand name;
• function implementing the subcommand;
• short description;
• parameters as a []Param.

With this change, a group may now also be a pair of arguments:

• subcommand name;
• Subcmd object.