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 a silent option to ignore warnings #23

Closed
wants to merge 3 commits into from
Closed

Add a silent option to ignore warnings #23

wants to merge 3 commits into from

Conversation

tgroshon
Copy link

Introduces a silent keyword argument to set the module into silent mode: read_dotenv(silent=True). Prevents UserWarning's.

fixes issue #12

Tommy Groshong added 3 commits August 24, 2016 13:41
Introduces a `silent` keyword argument to set the module into silent mode: `read_dotenv(silent=True)`.  Prevents `UserWarning`'s.

fixes issue #12
Suppress warnings when silent is true
@tgroshon
Copy link
Author

I see the build problem and will address. Will replace with a regular kw arg and no * collector.

@merwok
Copy link
Contributor

merwok commented Jan 17, 2017

I was surprised by the warning. I had a server misconfiguration that made the env file not readable by my server process, and had to dig in logs to find that (the actual error happened a bit later when the code tries to read envvars). It would have been better for me to get an exception instead of a warning. So could we get three possible behaviours here: do nothing, warn, raise exception?

@tgroshon
Copy link
Author

I like that idea, but I am not sure of the UI for that kind of behavior. Any ideas?

@merwok
Copy link
Contributor

merwok commented Jan 17, 2017

If you don’t mind ternary options, a UI could be:

  • silent=True → do nothing
  • silent=None → warn (default)
  • silent=False → exception

Also, ignore_missing may be more obvious than silent.

@merwok
Copy link
Contributor

merwok commented Jan 17, 2017

A complementary idea would be to use logging instead of warnings. Logging is more appropriate according to https://docs.python.org/2/howto/logging.html#when-to-use-logging and easy to configure.

@tgroshon
Copy link
Author

I also like the idea of replacing warnings with logging. Then a user could specify their log level easily in different environments (DEBUG in development or testing, WARNING in production, etc.).

@tgroshon
Copy link
Author

i'm going to close this PR. We can move this discussion back over to issue #12 .

@tgroshon tgroshon closed this Jan 17, 2017
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

Successfully merging this pull request may close these issues.

None yet

2 participants