-
Notifications
You must be signed in to change notification settings - Fork 50
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
Add Support for Reading Environment Variables from .env Files #42
Comments
Super interesting idea. I've never thought of it. I usually just |
I’d be happy to work on adding this feature if the package is open to contributions! |
Sure. Just note a few things.
|
I propose allowing the user to specify a .env file name, with a default fallback to .env if none is provided. |
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... |
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. |
I forget to source my .env all the time. I think that is the benefit. It would be for dev purposes. |
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 😂). |
Hey @ardan-bkennedy , I’ve started implementing this feature. Parsing lines in .env files has many cases to handle, so I was wondering if it’s okay to use some code snippets from this open-source package, as it covers the same logic and is stable: https://github.com/joho/godotenv/blob/main/parser.go. |
That's fine if we bring it in, inside it's own source code file with the proper licensing documentation on top. |
I would implement this like we did the yaml package. Add a new package that implements the interface, but try not to use this code as a dependency, bring it in. |
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.The text was updated successfully, but these errors were encountered: