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

Add Support for Reading Environment Variables from .env Files #42

Open
Adembc opened this issue Oct 25, 2024 · 11 comments
Open

Add Support for Reading Environment Variables from .env Files #42

Adembc opened this issue Oct 25, 2024 · 11 comments

Comments

@Adembc
Copy link

Adembc commented Oct 25, 2024

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
Copy link
Collaborator

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
Copy link
Author

Adembc commented Oct 25, 2024

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

@ardan-bkennedy
Copy link
Collaborator

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
Copy link
Author

Adembc commented Oct 25, 2024

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

@ardan-bkennedy
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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

@dainfoo
Copy link

dainfoo commented Oct 29, 2024

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 😂).

@Adembc
Copy link
Author

Adembc commented Nov 13, 2024

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.

@ardan-bkennedy
Copy link
Collaborator

That's fine if we bring it in, inside it's own source code file with the proper licensing documentation on top.

@ardan-bkennedy
Copy link
Collaborator

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.

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

4 participants