feat: read pointed file of environment variables using github.com/joho/godotenv

[smoke]

refs #347 (comment)

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.

[smoke]

I have noticed that missing .env is considered a fatal error, where it should not be ...
now reconsidering the options

[smoke]

Considered to expose option to read file pointed via -env-file and as well to skip any errors while doing that.

[smoke]

@mfridman I have rebased this branch, please take a look.

[mfridman]

Related issue (and what this would close if merged) #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.

[smoke]

@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