Gain insights into writing professional command-line programs in Go. Delve into structuring Go programs, writing idiomatic code, testing effectively, and impressing users and managers.

write professional command  - line programs in Go.png

data.tar.gz

Go run main.go

Run main.sh

Run go test

Run go test2

GoLive

GoLiveTesting

Multi-git-Custom

Pre+main-v0.2

Main_to_cmd

Run go test-Coverage

Ginkgo

Ginkgo-BDD

Ginkgo-e2e

Cobra

Cobra-NoInstall

Cobra-NoInstall-FullApp

Final_Cobra_Multi-git

Viper

Viper-etcd

Viper-Cobra

SelfUpdating

Make

Special build

Embedding_Data

Go run main.go-Simple

In this course you will learn why Go is an awesome language for writing command-line programs. You will learn how to structure your Go programs, how to write idiomatic Go code, how to test your programs and how to amaze your users, peers and managers. 

The focus is on command-line programs in order to keep the course down to earth, but most of the principles and best practices you will learn apply to any Go program.

Write Professional Command-line Programs in Go

Viper supports many modes of configuration and it integrates with Cobra. In particular Viper supports configuration files in many formats, environment variables, command-line flags and remote key value stores. It also provides advanced access mechanisms to your configuration like nested access and marshaling from Go structs.

# Overview

[Viper](https://github.com/spf13/viper) aims to address all your configuration needs for Go programs. It is designed to support any use case from command-line programs all the way to 12-factor distributed apps. 

It is called Viper because it is a companion to Cobra. Of course, it has a cool logo







Let's look at Viper API, data structures and the various mechanisms and modes it brings to the table.

# Foundations of Viper

Viper presents a pretty simple interface. Viper manages settings and you can get settings via a variety of GetXXX() functions for specific types. For example:

```
import (
	"fmt"
	"github.com/spf13/viper"
)

func main() {
	viper.Set("bool", true)
	viper.Set("int", 777)

	fmt.Println(viper.GetBool("bool"))
	fmt.Println(viper.GetInt("int"))
}

true
777
```

If you try to get a non-existent setting, Viper will NOT return an error. Instead, it will return the zero value of the type. For example, it will return `0` for integers and false for Boolean settings. You can also may use the `viper.Get()` function, which returns a generic `interface{}`.

```
func main() {
	fmt.Println(viper.GetInt("no-such-int"))
	fmt.Println(viper.GetBool("no-such-bool"))
	fmt.Println(viper.Get("no-such-setting"))

	viper.Set("int", 777)
	fmt.Println(viper.Get("int"))
}

0
false
<nil>
777
```

There are no type conversion errors with Viper. When you get a setting with the wrong type, Viper will attempt to convert it, and if it can't, it will return the zero value. For example, here we set "number" to the integer 888 and get it as a string, which works just fine. However, when we set "text" to the string "some text" and try to get it as an integer, the result is 0.

```
func main() {
	viper.Set("number", 888)
	fmt.Println(viper.GetString("number"))

	viper.Set("text", "some text")
	fmt.Println(viper.GetInt("text"))
}

888
0
```

This can be dangerous because Viper provides you with an automatic type conversion system, but it doesn't protect you from type mismatches.

# Order of precedence

Viper supports multiple forms of configurations and is designed around the notion that the same setting can be defined in multiple modes. For example, you can have a setting that is defined in an environment variable, in a command-line flag and in a configuration file.

In this case, Viper resolves the actual value of the setting using a predefined order of precedence:

1. Explicit call to Set()
2. Command-line flag
3. Environment variable
4. Configuration file
5. Key/value store
6. Default

So, explicit calls to Set() override all other configuration modes. If no configuration is specified, there is always a default. When you call `viper.Get()`, you will always get something.

However, there is a way to check if a setting was configured or not via the `viper.IsSet()` function:

```
func main() {
	viper.Set("value", 55)

	if viper.IsSet("value") {
		fmt.Println("value:", viper.Get("value"))
	}

	if !viper.IsSet("no-such-key") {
		fmt.Println("'no-such-key' is not set")
	}
}
```

# Viper and configuration objects

Viper supports arbitrarily complex Go objects as configuration values. The signature of the basic Get() and Set() functions uses the generic interface{} type. This means that any Go value can be a Viper configuration item:

```
type ConfigItem struct {
	Text string
	Number int
}

func main() {
	viper.Set("item", &ConfigItem{"Hi", 44})
	item := viper.Get("item")
	fmt.Println("item:", item)
}

item: &{Hi 44}
```

If we want to work with the specific fields, we can tell Viper to unmarshal a key into a struct:

```
func main() {
	viper.Set("item", &ConfigItem{"Hi", 44})

	var item ConfigItem

	err := viper.UnmarshalKey("item", &item)
	if err != nil {
		fmt.Printf("Unmarshal failed, %v\n", err)
	}

	fmt.Println("text:", item.Text, "number:", item.Number)
}

text: Hi number: 44

```

Note, that in case of unmarshalling Viper does return an error if something goes wrong:

```
func main() {
	viper.Set("item", 123)

	var item ConfigItem

	err := viper.UnmarshalKey("item", &item)
	if err != nil {
		fmt.Printf("Unmarshal failed, %v\n", err)
	}
}

Unmarshal failed, '' expected a map, got 'int'
```

> Run `viper` codes in the following application.


In this lesson, you'll meet Viper, the configuration library from the creator of Cobra.

Introduction to Viper

Overview

Restructuring multi-git

Testing 1,2,3...

Adding Smart Command-Line Parsing

Adding Advanced Configuration

Adding Bells and Whistles

Summary

Introduction to Viper