Top Related Projects
Quick Overview
alexflint/go-arg is a Go library for parsing command-line arguments using struct tags. It provides a simple and intuitive way to define command-line interfaces for Go applications, automatically generating help text and handling various argument types.
Pros
- Easy to use with struct tags for defining arguments
- Automatically generates help text and usage information
- Supports nested structs and custom types
- Provides built-in validation for required fields and custom validation functions
Cons
- Limited support for complex command-line structures (e.g., subcommands)
- May require additional configuration for advanced use cases
- Not as feature-rich as some other CLI libraries in the Go ecosystem
- Learning curve for users unfamiliar with struct tags in Go
Code Examples
- Basic usage:
type Args struct {
Foo string
Bar bool
}
func main() {
var args Args
arg.MustParse(&args)
fmt.Println(args.Foo, args.Bar)
}
- Custom argument names and descriptions:
type Args struct {
Verbose bool `arg:"-v" help:"enable verbose logging"`
Output string `arg:"-o" help:"output file"`
}
func main() {
var args Args
arg.MustParse(&args)
}
- Required arguments and default values:
type Args struct {
InputFile string `arg:"positional,required" help:"input file to process"`
MaxLines int `arg:"-m" default:"100" help:"maximum number of lines to process"`
}
func main() {
var args Args
arg.MustParse(&args)
}
Getting Started
To use alexflint/go-arg in your Go project, follow these steps:
-
Install the library:
go get github.com/alexflint/go-arg
-
Import the library in your Go code:
import "github.com/alexflint/go-arg"
-
Define a struct with the desired command-line arguments:
type Args struct { Verbose bool `arg:"-v" help:"enable verbose mode"` Input string `arg:"positional,required" help:"input file"` Output string `arg:"-o" help:"output file"` }
-
Parse the arguments in your main function:
func main() { var args Args arg.MustParse(&args) // Use args.Verbose, args.Input, and args.Output in your program }
Competitor Comparisons
A Commander for modern Go CLI interactions
Pros of Cobra
- More feature-rich, supporting complex command structures and subcommands
- Extensive documentation and widespread adoption in the Go community
- Built-in support for generating shell completions and man pages
Cons of Cobra
- Steeper learning curve due to its more complex API
- Can be overkill for simple CLI applications
- Requires more boilerplate code for basic functionality
Code Comparison
go-arg:
type Args struct {
Foo string
Bar int
}
func main() {
var args Args
arg.MustParse(&args)
}
Cobra:
var rootCmd = &cobra.Command{
Use: "app",
Short: "A brief description of your application",
Run: func(cmd *cobra.Command, args []string) {
// Your logic here
},
}
func main() {
rootCmd.Execute()
}
go-arg is more straightforward for simple CLI apps, using struct tags for configuration. Cobra requires more setup but offers greater flexibility for complex command structures.
go-arg automatically generates help text from struct fields, while Cobra requires manual definition of flags and commands.
Cobra is better suited for large-scale CLI applications with multiple subcommands, while go-arg excels in simplicity for smaller projects with straightforward argument parsing needs.
A Go library for implementing command-line interfaces.
Pros of cli
- More flexible and customizable for complex CLI applications
- Supports subcommands and nested command structures
- Provides built-in help generation and version flag handling
Cons of cli
- Requires more boilerplate code for simple use cases
- Steeper learning curve compared to go-arg's simpler API
- Less automatic parsing of struct fields and tags
Code Comparison
cli:
type CLI struct {
Commands map[string]cli.CommandFactory
}
c := cli.NewCLI("app", "1.0.0")
c.Args = os.Args[1:]
c.Commands = map[string]cli.CommandFactory{
"foo": fooCommandFactory,
}
go-arg:
type args struct {
Foo string `arg:"required,help:do the foo thing"`
}
var args args
arg.MustParse(&args)
Summary
cli is better suited for complex CLI applications with multiple subcommands, while go-arg excels in simplicity for straightforward command-line tools. cli offers more flexibility and built-in features but requires more setup, whereas go-arg provides a more intuitive API with less code for basic use cases. The choice between the two depends on the specific requirements and complexity of your CLI application.
CONTRIBUTIONS ONLY: A Go (golang) command line and flag parser
Pros of kingpin
- More feature-rich with support for commands, subcommands, and flags
- Offers more customization options for help output and error handling
- Provides built-in support for version flags and completion
Cons of kingpin
- More complex API, which may lead to a steeper learning curve
- Requires more boilerplate code for basic use cases
- Less intuitive for simple command-line applications
Code Comparison
kingpin:
var (
verbose = kingpin.Flag("verbose", "Verbose mode.").Short('v').Bool()
name = kingpin.Arg("name", "Name of user.").Required().String()
)
func main() {
kingpin.Parse()
// Use flags and arguments
}
go-arg:
var args struct {
Verbose bool `arg:"-v" help:"verbose mode"`
Name string `arg:"positional,required" help:"name of user"`
}
func main() {
arg.MustParse(&args)
// Use args directly
}
Both kingpin and go-arg are popular command-line argument parsing libraries for Go. kingpin offers more advanced features and customization options, making it suitable for complex CLI applications. However, this comes at the cost of a more complex API and increased boilerplate code. go-arg, on the other hand, provides a simpler and more intuitive approach, especially for basic use cases, but may lack some advanced features found in kingpin.
go command line option parser
Pros of go-flags
- More feature-rich with advanced options like command completion and man page generation
- Supports a wider range of flag types and custom types
- Offers more flexibility in flag naming and aliasing
Cons of go-flags
- More complex API and steeper learning curve
- Larger codebase and potentially higher overhead
- Less idiomatic Go syntax compared to go-arg
Code Comparison
go-flags:
type Options struct {
Name string `short:"n" long:"name" description:"A name" required:"true"`
Value int `short:"v" long:"value" description:"A value"`
}
var opts Options
_, err := flags.Parse(&opts)
go-arg:
type Args struct {
Name string `arg:"required" help:"A name"`
Value int `help:"A value"`
}
var args Args
arg.MustParse(&args)
go-flags offers more control over flag naming and options, while go-arg provides a simpler, more Go-like syntax. go-flags requires explicit error handling, whereas go-arg uses panic for simplicity. Both libraries support struct tags for defining command-line arguments, but go-flags offers more customization options at the cost of increased complexity.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
go-arg
Struct-based argument parsing for Go
Declare command line arguments for your program by defining a struct.
var args struct {
Foo string
Bar bool
}
arg.MustParse(&args)
fmt.Println(args.Foo, args.Bar)
$ ./example --foo=hello --bar
hello true
Installation
go get github.com/alexflint/go-arg
Required arguments
var args struct {
ID int `arg:"required"`
Timeout time.Duration
}
arg.MustParse(&args)
$ ./example
Usage: example --id ID [--timeout TIMEOUT]
error: --id is required
Positional arguments
var args struct {
Input string `arg:"positional"`
Output []string `arg:"positional"`
}
arg.MustParse(&args)
fmt.Println("Input:", args.Input)
fmt.Println("Output:", args.Output)
$ ./example src.txt x.out y.out z.out
Input: src.txt
Output: [x.out y.out z.out]
Environment variables
var args struct {
Workers int `arg:"env"`
}
arg.MustParse(&args)
fmt.Println("Workers:", args.Workers)
$ WORKERS=4 ./example
Workers: 4
$ WORKERS=4 ./example --workers=6
Workers: 6
You can also override the name of the environment variable:
var args struct {
Workers int `arg:"env:NUM_WORKERS"`
}
arg.MustParse(&args)
fmt.Println("Workers:", args.Workers)
$ NUM_WORKERS=4 ./example
Workers: 4
You can provide multiple values in environment variables using commas:
var args struct {
Workers []int `arg:"env"`
}
arg.MustParse(&args)
fmt.Println("Workers:", args.Workers)
$ WORKERS='1,99' ./example
Workers: [1 99]
Command line arguments take precedence over environment variables:
var args struct {
Workers int `arg:"--count,env:NUM_WORKERS"`
}
arg.MustParse(&args)
fmt.Println("Workers:", args.Workers)
$ NUM_WORKERS=6 ./example
Workers: 6
$ NUM_WORKERS=6 ./example --count 4
Workers: 4
Usage strings
var args struct {
Input string `arg:"positional"`
Output []string `arg:"positional"`
Verbose bool `arg:"-v,--verbose" help:"verbosity level"`
Dataset string `help:"dataset to use"`
Optimize int `arg:"-O" help:"optimization level"`
}
arg.MustParse(&args)
$ ./example -h
Usage: [--verbose] [--dataset DATASET] [--optimize OPTIMIZE] [--help] INPUT [OUTPUT [OUTPUT ...]]
Positional arguments:
INPUT
OUTPUT
Options:
--verbose, -v verbosity level
--dataset DATASET dataset to use
--optimize OPTIMIZE, -O OPTIMIZE
optimization level
--help, -h print this help message
Default values
var args struct {
Foo string `default:"abc"`
Bar bool
}
arg.MustParse(&args)
Command line arguments take precedence over environment variables, which take precedence over default values. This means that we check whether a certain option was provided on the command line, then if not, we check for an environment variable (only if an env
tag was provided), then if none is found, we check for a default
tag containing a default value.
var args struct {
Test string `arg:"-t,env:TEST" default:"something"`
}
arg.MustParse(&args)
Ignoring environment variables and/or default values
var args struct {
Test string `arg:"-t,env:TEST" default:"something"`
}
p, err := arg.NewParser(arg.Config{
IgnoreEnv: true,
IgnoreDefault: true,
}, &args)
err = p.Parse(os.Args)
Arguments with multiple values
var args struct {
Database string
IDs []int64
}
arg.MustParse(&args)
fmt.Printf("Fetching the following IDs from %s: %q", args.Database, args.IDs)
./example -database foo -ids 1 2 3
Fetching the following IDs from foo: [1 2 3]
Arguments that can be specified multiple times, mixed with positionals
var args struct {
Commands []string `arg:"-c,separate"`
Files []string `arg:"-f,separate"`
Databases []string `arg:"positional"`
}
arg.MustParse(&args)
./example -c cmd1 db1 -f file1 db2 -c cmd2 -f file2 -f file3 db3 -c cmd3
Commands: [cmd1 cmd2 cmd3]
Files [file1 file2 file3]
Databases [db1 db2 db3]
Arguments with keys and values
var args struct {
UserIDs map[string]int
}
arg.MustParse(&args)
fmt.Println(args.UserIDs)
./example --userids john=123 mary=456
map[john:123 mary:456]
Version strings
type args struct {
...
}
func (args) Version() string {
return "someprogram 4.3.0"
}
func main() {
var args args
arg.MustParse(&args)
}
$ ./example --version
someprogram 4.3.0
Note If a
--version
flag is defined inargs
or any subcommand, it overrides the built-in versioning.
Custom validation
var args struct {
Foo string
Bar string
}
p := arg.MustParse(&args)
if args.Foo == "" && args.Bar == "" {
p.Fail("you must provide either --foo or --bar")
}
./example
Usage: samples [--foo FOO] [--bar BAR]
error: you must provide either --foo or --bar
Overriding option names
var args struct {
Short string `arg:"-s"`
Long string `arg:"--custom-long-option"`
ShortAndLong string `arg:"-x,--my-option"`
OnlyShort string `arg:"-o,--"`
}
arg.MustParse(&args)
$ ./example --help
Usage: example [-o ONLYSHORT] [--short SHORT] [--custom-long-option CUSTOM-LONG-OPTION] [--my-option MY-OPTION]
Options:
--short SHORT, -s SHORT
--custom-long-option CUSTOM-LONG-OPTION
--my-option MY-OPTION, -x MY-OPTION
-o ONLYSHORT
--help, -h display this help and exit
Embedded structs
The fields of embedded structs are treated just like regular fields:
type DatabaseOptions struct {
Host string
Username string
Password string
}
type LogOptions struct {
LogFile string
Verbose bool
}
func main() {
var args struct {
DatabaseOptions
LogOptions
}
arg.MustParse(&args)
}
As usual, any field tagged with arg:"-"
is ignored.
Supported types
The following types may be used as arguments:
- built-in integer types:
int, int8, int16, int32, int64, byte, rune
- built-in floating point types:
float32, float64
- strings
- booleans
- URLs represented as
url.URL
- time durations represented as
time.Duration
- email addresses represented as
mail.Address
- MAC addresses represented as
net.HardwareAddr
- pointers to any of the above
- slices of any of the above
- maps using any of the above as keys and values
- any type that implements
encoding.TextUnmarshaler
Custom parsing
Implement encoding.TextUnmarshaler
to define your own parsing logic.
// Accepts command line arguments of the form "head.tail"
type NameDotName struct {
Head, Tail string
}
func (n *NameDotName) UnmarshalText(b []byte) error {
s := string(b)
pos := strings.Index(s, ".")
if pos == -1 {
return fmt.Errorf("missing period in %s", s)
}
n.Head = s[:pos]
n.Tail = s[pos+1:]
return nil
}
func main() {
var args struct {
Name NameDotName
}
arg.MustParse(&args)
fmt.Printf("%#v\n", args.Name)
}
$ ./example --name=foo.bar
main.NameDotName{Head:"foo", Tail:"bar"}
$ ./example --name=oops
Usage: example [--name NAME]
error: error processing --name: missing period in "oops"
Custom parsing with default values
Implement encoding.TextMarshaler
to define your own default value strings:
// Accepts command line arguments of the form "head.tail"
type NameDotName struct {
Head, Tail string
}
func (n *NameDotName) UnmarshalText(b []byte) error {
// same as previous example
}
// this is only needed if you want to display a default value in the usage string
func (n *NameDotName) MarshalText() ([]byte, error) {
return []byte(fmt.Sprintf("%s.%s", n.Head, n.Tail)), nil
}
func main() {
var args struct {
Name NameDotName `default:"file.txt"`
}
arg.MustParse(&args)
fmt.Printf("%#v\n", args.Name)
}
$ ./example --help
Usage: test [--name NAME]
Options:
--name NAME [default: file.txt]
--help, -h display this help and exit
$ ./example
main.NameDotName{Head:"file", Tail:"txt"}
Custom placeholders
Use the placeholder
tag to control which placeholder text is used in the usage text.
var args struct {
Input string `arg:"positional" placeholder:"SRC"`
Output []string `arg:"positional" placeholder:"DST"`
Optimize int `arg:"-O" help:"optimization level" placeholder:"LEVEL"`
MaxJobs int `arg:"-j" help:"maximum number of simultaneous jobs" placeholder:"N"`
}
arg.MustParse(&args)
$ ./example -h
Usage: example [--optimize LEVEL] [--maxjobs N] SRC [DST [DST ...]]
Positional arguments:
SRC
DST
Options:
--optimize LEVEL, -O LEVEL
optimization level
--maxjobs N, -j N maximum number of simultaneous jobs
--help, -h display this help and exit
Description strings
A descriptive message can be added at the top of the help text by implementing
a Description
function that returns a string.
type args struct {
Foo string
}
func (args) Description() string {
return "this program does this and that"
}
func main() {
var args args
arg.MustParse(&args)
}
$ ./example -h
this program does this and that
Usage: example [--foo FOO]
Options:
--foo FOO
--help, -h display this help and exit
Similarly an epilogue can be added at the end of the help text by implementing
the Epilogue
function.
type args struct {
Foo string
}
func (args) Epilogue() string {
return "For more information visit github.com/alexflint/go-arg"
}
func main() {
var args args
arg.MustParse(&args)
}
$ ./example -h
Usage: example [--foo FOO]
Options:
--foo FOO
--help, -h display this help and exit
For more information visit github.com/alexflint/go-arg
Subcommands
Subcommands are commonly used in tools that wish to group multiple functions into a single program. An example is the git
tool:
$ git checkout [arguments specific to checking out code]
$ git commit [arguments specific to committing]
$ git push [arguments specific to pushing]
The strings "checkout", "commit", and "push" are different from simple positional arguments because the options available to the user change depending on which subcommand they choose.
This can be implemented with go-arg
as follows:
type CheckoutCmd struct {
Branch string `arg:"positional"`
Track bool `arg:"-t"`
}
type CommitCmd struct {
All bool `arg:"-a"`
Message string `arg:"-m"`
}
type PushCmd struct {
Remote string `arg:"positional"`
Branch string `arg:"positional"`
SetUpstream bool `arg:"-u"`
}
var args struct {
Checkout *CheckoutCmd `arg:"subcommand:checkout"`
Commit *CommitCmd `arg:"subcommand:commit"`
Push *PushCmd `arg:"subcommand:push"`
Quiet bool `arg:"-q"` // this flag is global to all subcommands
}
arg.MustParse(&args)
switch {
case args.Checkout != nil:
fmt.Printf("checkout requested for branch %s\n", args.Checkout.Branch)
case args.Commit != nil:
fmt.Printf("commit requested with message \"%s\"\n", args.Commit.Message)
case args.Push != nil:
fmt.Printf("push requested from %s to %s\n", args.Push.Branch, args.Push.Remote)
}
Some additional rules apply when working with subcommands:
- The
subcommand
tag can only be used with fields that are pointers to structs - Any struct that contains a subcommand must not contain any positionals
This package allows to have a program that accepts subcommands, but also does something else when no subcommands are specified. If on the other hand you want the program to terminate when no subcommands are specified, the recommended way is:
p := arg.MustParse(&args)
if p.Subcommand() == nil {
p.Fail("missing subcommand")
}
Custom handling of --help and --version
The following reproduces the internal logic of MustParse
for the simple case where
you are not using subcommands or --version. This allows you to respond
programatically to --help, and to any errors that come up.
var args struct {
Something string
}
p, err := arg.NewParser(arg.Config{}, &args)
if err != nil {
log.Fatalf("there was an error in the definition of the Go struct: %v", err)
}
err = p.Parse(os.Args[1:])
switch {
case err == arg.ErrHelp: // indicates that user wrote "--help" on command line
p.WriteHelp(os.Stdout)
os.Exit(0)
case err != nil:
fmt.Printf("error: %v\n", err)
p.WriteUsage(os.Stdout)
os.Exit(1)
}
$ go run ./example --help
Usage: ./example --something SOMETHING
Options:
--something SOMETHING
--help, -h display this help and exit
$ ./example --wrong
error: unknown argument --wrong
Usage: ./example --something SOMETHING
$ ./example
error: --something is required
Usage: ./example --something SOMETHING
To also handle --version programatically, use the following:
type args struct {
Something string
}
func (args) Version() string {
return "1.2.3"
}
func main() {
var args args
p, err := arg.NewParser(arg.Config{}, &args)
if err != nil {
log.Fatalf("there was an error in the definition of the Go struct: %v", err)
}
err = p.Parse(os.Args[1:])
switch {
case err == arg.ErrHelp: // found "--help" on command line
p.WriteHelp(os.Stdout)
os.Exit(0)
case err == arg.ErrVersion: // found "--version" on command line
fmt.Println(args.Version())
os.Exit(0)
case err != nil:
fmt.Printf("error: %v\n", err)
p.WriteUsage(os.Stdout)
os.Exit(1)
}
fmt.Printf("got %q\n", args.Something)
}
$ ./example --version
1.2.3
$ go run ./example --help
1.2.3
Usage: example --something SOMETHING
Options:
--something SOMETHING
--help, -h display this help and exit
$ ./example --wrong
1.2.3
error: unknown argument --wrong
Usage: example --something SOMETHING
$ ./example
error: --something is required
Usage: example --something SOMETHING
To generate subcommand-specific help messages, use the following most general version (this also works in absence of subcommands but is a bit more complex):
type fetchCmd struct {
Count int
}
type args struct {
Something string
Fetch *fetchCmd `arg:"subcommand"`
}
func (args) Version() string {
return "1.2.3"
}
func main() {
var args args
p, err := arg.NewParser(arg.Config{}, &args)
if err != nil {
log.Fatalf("there was an error in the definition of the Go struct: %v", err)
}
err = p.Parse(os.Args[1:])
switch {
case err == arg.ErrHelp: // found "--help" on command line
p.WriteHelpForSubcommand(os.Stdout, p.SubcommandNames()...)
os.Exit(0)
case err == arg.ErrVersion: // found "--version" on command line
fmt.Println(args.Version())
os.Exit(0)
case err != nil:
fmt.Printf("error: %v\n", err)
p.WriteUsageForSubcommand(os.Stdout, p.SubcommandNames()...)
os.Exit(1)
}
}```
```shell
$ ./example --version
1.2.3
$ ./example --help
1.2.3
Usage: example [--something SOMETHING] <command> [<args>]
Options:
--something SOMETHING
--help, -h display this help and exit
--version display version and exit
Commands:
fetch
$ ./example fetch --help
1.2.3
Usage: example fetch [--count COUNT]
Options:
--count COUNT
Global options:
--something SOMETHING
--help, -h display this help and exit
--version display version and exit
API Documentation
https://pkg.go.dev/github.com/alexflint/go-arg
Rationale
There are many command line argument parsing libraries for Go, including one in the standard library, so why build another?
The flag
library that ships in the standard library seems awkward to me. Positional arguments must precede options, so ./prog x --foo=1
does what you expect but ./prog --foo=1 x
does not. It also does not allow arguments to have both long (--foo
) and short (-f
) forms.
Many third-party argument parsing libraries are great for writing sophisticated command line interfaces, but feel to me like overkill for a simple script with a few flags.
The idea behind go-arg
is that Go already has an excellent way to describe data structures using structs, so there is no need to develop additional levels of abstraction. Instead of one API to specify which arguments your program accepts, and then another API to get the values of those arguments, go-arg
replaces both with a single struct.
Backward compatibility notes
Earlier versions of this library required the help text to be part of the arg
tag. This is still supported but is now deprecated. Instead, you should use a separate help
tag, described above, which makes it possible to include commas inside help text.
Top Related Projects
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot