gobuffalo / envy

Envy makes working with ENV variables in Go trivial.

Buffalo Documentation

This is the repository for https://www.gobuffalo.io, the official website of the Buffalo ecosystem.

This documentation contains:

• The Buffalo Documentation
• The Pop Documentation

Contributing

Contributing to this documentation site is a great, and easy, way to help make Buffalo better!

Note that this repository is only about Buffalo ecosystem documentation. If you want to contribute to the ecosystem itself, please refer to the concerned repository:

• Buffalo
• Buffalo CLI
• Pop
• Plush

See the contribution guide for more info about how to contribute.

envy's Issues

bug: Don't override system environment variables

Description

Description

Please don't override the shell/system's environment variables in your init() method.

https://github.com/gobuffalo/envy/blob/v1/envy.go#L85

Expected Behavior

Ideally don't cause any side effects that affect code outside your modules at all in your init().

https://github.com/gobuffalo/envy/blame/v1/envy.go#L34-L37

However, at a minimum, the environment variables from the shell/system should take precedence unless someone explicitly says otherwise.

Actual Behavior

In my case, a dependency of a dependency is using envy. I was very confused as to what was going on with my environment variables.

Simply including envy in a project breaks the ability for any other modules to use dotenv's Load() functionality, because Overload() has already been called.

To Reproduce

1. In any project using envy...
2. Create a .env with an environment variable set to one value.
3. Execute the project in a shell that already has the environment variable defined.
4. Note that the value in .env overwrote the shell defined environment variable.

Additional Context

No response

should `CurrentPackage()` be deprecated?

This implementation is based on the legacy layout of GOPATH which is deprecated now. It seems like CurrentModule() should be used for the same purpose. Any idea?

envy/envy.go

Lines 218 to 232 in 3dbe4c9

	func importPath(path string) string {
	path = strings.TrimPrefix(path, "/private")
	for _, gopath := range GoPaths() {
	srcpath := filepath.Join(gopath, "src")
	rel, err := filepath.Rel(srcpath, path)
	if err == nil {
	return filepath.ToSlash(rel)
	}
	}
	// fallback to trim
	rel := strings.TrimPrefix(path, filepath.Join(GoPath(), "src"))
	rel = strings.TrimPrefix(rel, string(filepath.Separator))
	return filepath.ToSlash(rel)
	}

envy/envy.go

Lines 254 to 259 in 3dbe4c9

	func CurrentPackage() string {
	if Mods() {
	}
	pwd, _ := os.Getwd()
	return importPath(pwd)
	}

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

Progress

• #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?

Support `.env` files

gobuffalo/buffalo#516

It would be great if envy loaded .env files if they exist.

Envy Breaks Packr2 GoMod=off

our project is not using modules (one of the packages prevents this so we currently can't migrate to modules). As a result we have modules turned off.
As part of our build/deployment we go get packr2 (which pulls in envy). The latest release of envy always assumes modules is turned on and therefore our packr2 command fails with

Error: go.mod cannot be read or does not exist while go module is enabled

Since I can't specify a version when using go get, I am hoping there is an alternate way to get the previous version that supports non-modules.

Unknown import path in envy.go file

go mod encounters an error when trying to load one of the packages. I think the package location ("github.com/rogpeppe/go-internal/modfile") might have been moved.

go: finding github.com/rogpeppe/go-internal/modfile latest

../../../go/pkg/mod/github.com/gobuffalo/[email protected]/envy.go:26:2: unknown import path "github.com/rogpeppe/go-internal/modfile": cannot find module providing package github.com/rogpeppe/go-internal/modfile

envy is trying to load .env files even when not asked to

Why is this module I had never heard about spewing on the output of Hugo, among others?

ecthelion ~/go>./bin/hugo --help
[ENVY] unable to load env file(s) on init: open .env: no such file or directory
hugo is the main command, used to build your Hugo site.

Hugo is a Fast and Flexible Static Site Generator
built with love by spf13 and friends in Go.

Complete documentation is available at http://gohugo.io/.
...

README.md claims "By default, no env files will be loaded." but envy.go is clearly trying to do so in init(), and what's worse, outputting an unsolicited error message on stderr.

Here is a minimal reproduction case:

ecthelion ~/hugo/fts5index>cat envy.go 
package main

import (
	"fmt"
	"github.com/gobuffalo/envy"
)

func main() {
	fmt.Println(envy.GO111MODULE)
}
ecthelion ~/hugo/fts5index>go run envy.go
[ENVY] unable to load env file(s) on init: open .env: no such file or directory
GO111MODULE

License for envy is missing

Hi,

I'd like to create a package of envy for Debian. However, I cannot proceed because the code does not have a license, neither in the source code comments nor as a separate file. As it stands, Debian would not be permitted to distribute your code.

I assume from your other repositories that the license is intended to be MIT, but could you clarify this for me, please? Ideally you could just include the file LICENSE.txt.

Regards,
Tobias

envy overrides environment variables

Is it possible for envy.go to use godotenv.Load rather than godotenv.Overload? The current code causes any variable defined in .env to override the environment. Removing all side-effects of the library would probably be best (i.e. removing the init function), but if Load and loadEnv really need to run, then godotenv.Load would at least not change the environment in unexpected ways.

Example

example/main.go

package main

import (
	"fmt"
	"os"

	"github.com/joho/godotenv"
)

func main() {
	godotenv.Load()

	fmt.Println(envy.Get("VARIABLE", "default"))
}

example/.env

VARIABLE=fromFile

Invocation:

$ VARIABLE=fromEnv ./example

The above invocation should print fromEnv, since godotenv.Load overrides file configuration with environment configuration. Instead, it prints fromFile. This is a problem especially if the program in question is not directly dependent on envy, since the user may not know that godotenv.Overload is being called.

Thank you!

potential race condition using envy.Temp

There appears to be a potential race condition using envy.Temp. Since it does not have any kind of lock associated with it using it with goroutines could cause problems I think. Perhaps it should have it's own lock? (I guess it can't use gil because then it would deadlock with any Set methods called in the callback)

Feature Request - add docker swarm secret support

I would like to augment Envy so that it can retrieve secrets created in a Docker swarm. It would not be difficult and I am happy to write a pull request with the code. But before I do, I thought I'd checkin here to see if there is any interest in the proposal.
Cheers,
Rod

Open to new convenience functions?

Hi there -

In using envy I've run into a common issue when using environment variables: they can only hold strings, but sometimes a specific data type is needed. To address that we wrote a library, https://github.com/silinternational/php-env for PHP, with some handy methods like getArray as well as overloading the get method to parse out booleans properly. I'd like similar capabilities in Go, but before I write my own package I wanted to ask if you'd be open to some new functions being added to envy, for example I'd like to add:

// GetBool and MustGetBool will match the env string value for variations of "true" and return true, otherwise false
func GetBool(key string, default bool) bool {...}
func MustGetBool(key string) (bool, error) {...}

// GetArrayStrings and MustGetArrayStrings will split env string value by a delimiter and return as array of strings
func GetArrayStrings(key string, default []string) []string {...}
func MustGetArrayStrings(key string) ([]string, error) {...}

If you're open to these features being added I'll happily submit a PR with them for your review.

Thanks,
Phillip

GO_ENV not set to "test" because golang test environment not yet initialized

I had some test failures in my buffalo app that I traced back to the following problem: I was running go test ./actions/ manually rather than using buffalo test. GO_ENV was being automatically set to development inside my app, rather than test, causing a lot of confusion.

It looks like envy tries to detect the presence of the golang test environment, and if present, sets GO_ENV to test if otherwise undefined.

However this only works if the testing package has already been loaded by go before envy's init() func gets run. I don't think we can count on the order of package initialization if there is no explicit dependency between them. I've created a gist that demonstrates this.

In my own non-buffalo projects I have run into this general problem of how to detect when running in a unit test and setting the environment appropriately. I haven't come up with a good solution.