goose
goose copied to clipboard
feat: read pointed file of environment variables using `github.com/joho/godotenv`
refs https://github.com/pressly/goose/issues/347#issuecomment-1475334446
Defaulting to .env
in the current directory.
Skipping any error, including non-existing file or errors while parsing the file as no better options for now.
I have noticed that missing .env
is considered a fatal error, where it should not be ...
now reconsidering the options
Considered to expose option to read file pointed via -env-file
and as well to skip any errors while doing that.
@mfridman I have rebased this branch, please take a look.
Related issue (and what this would close if merged) https://github.com/pressly/goose/issues/329.
I'm still not convinced this is necessary, could you describe why the goose package and CLI should understand how to read/parse .env or .envrc files, as opposed to letting the user set their ENV variables how they want?
Afaics there are a lot of tools out there that do this well, e.g., https://direnv.net/, plain export
, etc.
It should be up to the user to set their ENV variables, instead of every tool in existence reading these files.
Maybe I'm missing something, but I'd like to understand why this is needed.
@mfridman That is a good point indeed and makes me wonder as well. Me and many others most likely are used to have such capability embedded and being cross-platform from tools like docker compose https://docs.docker.com/compose/environment-variables/set-environment-variables/ There are many ways to achieve that indeed, but in most cases it comes with good enough craftsmanship and is not easy to use for huge teams or less skilled people.
I personally love organizing different environments in different files e.g.
.env-dev
.env-qa
.env-stage
.env-others
then use goose to directly and seamlessly source from given env e.g.
goose -env-file .env-dev status
or direclty symlinking the relevant environment I am working with
ln -sf .env-dev .env
goose status