Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which takes precedence, the local .env or the actual environment variables? #59

Closed
coolaj86 opened this issue Sep 11, 2018 · 8 comments
Closed

Comments

@coolaj86
Copy link
Contributor

coolaj86 commented Sep 11, 2018

Just curious, for edge cases.

@joho
Copy link
Owner

joho commented Sep 12, 2018

A good question, let me try and figure out

  1. What we do
  2. What we should do (ie what does the ruby lib do)

@joho
Copy link
Owner

joho commented Sep 12, 2018

 ~/Projects/dotenvtest  ruby test.rb 
xTvDqw
foo$bar
123value
 ~/Projects/dotenvtest  BAR=other ruby test.rb 
xTvDqw
foo$bar
123other
 ~/Projects/dotenvtest  vim test.go 
 ~/Projects/dotenvtest  go run test.go
xTvDqw7
foo\
123value
 ~/Projects/dotenvtest  BAR=other go run test.go
xTvDqw7
foo\
123value

Environment variables should take preference (but don't), though there will probably be some edge cases in load vs overload.

Guess there's a 1.3.1 coming soon 😄

@coolaj86
Copy link
Contributor Author

coolaj86 commented Sep 12, 2018

Had this discussion with a coworker and he told me the same.

Each time a .env is loaded the prior takes precedence.

The rationale being

  • secrets go in memory only
  • .env.{dev,testing,staging,prod) have the endpoints go same tier services
  • .env (local) has personal preference for local dev and doesn’t get committed

@coolaj86
Copy link
Contributor Author

Thanks for looking into that and I look forward to the new version

@coolaj86
Copy link
Contributor Author

poke => v1.3.1 with precedence fixes?

@joho
Copy link
Owner

joho commented Sep 19, 2018

Hey sorry - hell of a hectic week as a sole startup founder and haven't been able to jump straight on this. Will try today or tomorrow. PRs always welcome if you need to hurry it along more than that.

@coolaj86
Copy link
Contributor Author

I starting digging into the code and it looked as if everything was in order.

I ran a test to be sure and it seems to me that all is working as it should:

test.go:

package main

import (
	"fmt"
	"os"

	"github.com/joho/godotenv"
)

func main() {
	os.Setenv("QUX", "nowyouseeme")
	godotenv.Load()
	godotenv.Load("second.env", "third.env")

	fmt.Printf("FOO=%s (%s)\n", os.Getenv("FOO"), "\"nowyouseeme\"")
	fmt.Printf("BAR=%s (%s)\n", os.Getenv("BAR"), "\"nowyouseeme\"")
	fmt.Printf("BAZ=%s (%s)\n", os.Getenv("BAZ"), "\"nowyouseeme\"")
	fmt.Printf("QUX=%s (%s)\n", os.Getenv("QUX"), "\"nowyouseeme\"")
	fmt.Printf("QUUX=%s (%s)\n", os.Getenv("QUUX"), "\"\"")
}

.env:

FOO=nowyouseeme
QUX=NOWYOUDONT

second.env:

FOO=NOWYOUDONT
BAR=nowyouseeme

third.env:

FOO=NOWYOUDONT2
BAR=NOWYOUDONT
BAZ=nowyouseeme

go run test.go:

# actual test results vs hard-coded expectation
FOO=nowyouseeme ("nowyouseeme")
BAR=nowyouseeme ("nowyouseeme")
BAZ=nowyouseeme ("nowyouseeme")
QUX=nowyouseeme ("nowyouseeme")
QUUX= ("")

FOO=DOUBLECHECKING go run test.go:

# result for FOO is preferring the existing environment, as expected
FOO=DOUBLECHECKING ("nowyouseeme")
BAR=nowyouseeme ("nowyouseeme")
BAZ=nowyouseeme ("nowyouseeme")
QUX=nowyouseeme ("nowyouseeme")
QUUX= ("")

@coolaj86
Copy link
Contributor Author

Here are some suggestions for updating the REAME: #60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants