Add Support for Reading Environment Variables from .env Files

[Adembc]

As far as I know, this package currently doesn’t support reading environment variables directly from a .env files. Would it be possible to consider adding this feature? It would make configuration management simpler and provide greater flexibility for developers.

[ardan-bkennedy]

Super interesting idea. I've never thought of it. I usually just source .env and keep going. I have to think about this more and quickly analyze how difficult it would be.

[Adembc]

I’d be happy to work on adding this feature if the package is open to contributions!

[ardan-bkennedy]

Sure. Just note a few things.

• If we need to touch existing code it gets harder for me to accept it without a more extensive review.
• Make sure all the tests are passing
• I think this should come before reading env vars from the environment. A set env var would override the .env file.
• Only look for .env in the current directory
• What do you plan to do when multiple .env files exist? dev.env, prod.env, etc.

[Adembc]

I propose allowing the user to specify a .env file name, with a default fallback to .env if none is provided.

[ardan-bkennedy]

You can't add that "allow the user", it needs to be default. Don't want to change or add an API. You just need to have a set of documented rules. If these files exist, this is the order...

[amoiseiev]

Out of curiosity, what are the actual benefits here?

I think using something like github.com/joho/godotenv is relatively standard. The benefits seem rather minor, but it's extra code to maintain and increases the risk of turning a rather lean library into Viper.

[ardan-bkennedy]

I forget to source my .env all the time. I think that is the benefit. It would be for dev purposes.

[dainfoo]

This feature, for me at least, is superb. Not having to add another dependency to my project just to source a .env file and use the same library in production and development is a big win, at least is what I think. I hate dependency hell (I know that is little, but if the Golang community do not look up, we will end up like the JavaScript community 😂).