proposal: envy v2 just as an enhanced version of os.Getenv()

[sio4]

Progress

• preparing v2 #41
• deprecating unwanted functions and clean up APIs

Direction

• just make it as an enhanced version of os.Getenv() families with virtual features like envy only env or sandbox
• also keep the feature of .env auto-loading or change it to manual
• make it simple and straight forward

Context

Envy is currently used by cli, buffalo, pop, meta v0, and clara. Also, the generated app uses it for mostly .env support which is a nice thing.

Currently, envy provides the following public functions:

1. Main Functions:

• Get(key string, value string) string - returns a value from the ENV, otherwise returns the given default
• MustGet(key string) (string, error) - returns a value from the ENV. no default but returns an error
• Set(key string, value string) - sets the value only into envy, not on the underlying ENV
• MustSet(key string, value string) error - sets the value into the underlying ENV, as well as envy.

2. Utilities:

• Environ() []string - returns an array of env representation
• Load(files ...string) error - load .env files
• Reload() - reload the ENV variables
• Map() map[string]string - returns all of the keys/values set in envy (no module uses it)
• Temp(f func()) - a kind of sandbox --> still useful for testing

3. Related to the golang environment:

• GoBin() string - returns "GO_BIN", just a wrapper of Get("GO_BIN", "go")
• GoPath() string - returns "GOPATH", just a wrapper of Get("GOPATH", "")
• GoPaths() []string - returns all possible GOPATH that are set --> could be deprecated
• InGoPath() bool - check if the current working directory is within GOPATH --> could be deprecated
• CurrentModule() (string, error) - return the module name from go.mod --> could be deprecated
• most of them are only used in meta v0

Also, it provides .env loading.

I don't think golang-related functions are still useful. All could be deprecated.

@gobuffalo/core-managers what do you think?

[charles-dyfis-net]

Removing the default Overload() would be very welcome. For traditional UNIX folks who expect var=value someprogram to override any file-based configuration (particularly in absence of godotenv.Overload() calls within someprogram's source), this is a serious violation of principle-of-least-surprise.