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

pytest should be overriding the interpreter's default warnings filter #2908

Closed
ncoghlan opened this Issue Nov 10, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@ncoghlan

ncoghlan commented Nov 10, 2017

When DeprecationWarning was hidden by default, the expectation was that 3rd party test runners would follow the unittest module's lead and re-enable them when running tests (see https://docs.python.org/3/whatsnew/2.7.html#changes-to-the-handling-of-deprecation-warnings and and https://docs.python.org/3/library/unittest.html#unittest.TextTestRunner)

This currently isn't the case for pytest - it requires developers to explicitly opt-in to seeing deprecation warnings, rather than requiring them to opt-out the way unittest does.

@merwok

This comment has been minimized.

Show comment
Hide comment
@merwok

merwok Nov 10, 2017

Would this be configurable? I’m all for getting warnings for code in my app, but not looking forward to the avalanche of messages from third-party django libs.

merwok commented Nov 10, 2017

Would this be configurable? I’m all for getting warnings for code in my app, but not looking forward to the avalanche of messages from third-party django libs.

@nicoddemus

This comment has been minimized.

Show comment
Hide comment
@nicoddemus

nicoddemus Nov 10, 2017

Member

Thanks @ncoghlan for the feedback!

Our intention is to do that when we refactor the warnings system. We had a few discussions about this but I can't find them in the issue tracker right now, I will see if I can find them tomorrow.

Member

nicoddemus commented Nov 10, 2017

Thanks @ncoghlan for the feedback!

Our intention is to do that when we refactor the warnings system. We had a few discussions about this but I can't find them in the issue tracker right now, I will see if I can find them tomorrow.

@nicoddemus

This comment has been minimized.

Show comment
Hide comment
@nicoddemus

nicoddemus Nov 10, 2017

Member

I’m all for getting warnings for code in my app, but not looking forward to the avalanche of messages from third-party django libs.

Currently warnings are already configurable by the filterwarnings ini option. An user would be able to for example ignore every DeprecationWarning if so desires.

Member

nicoddemus commented Nov 10, 2017

I’m all for getting warnings for code in my app, but not looking forward to the avalanche of messages from third-party django libs.

Currently warnings are already configurable by the filterwarnings ini option. An user would be able to for example ignore every DeprecationWarning if so desires.

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Nov 10, 2017

@merwok The only assumption we made at the interpreter level was that unconfigured test runners would be updated to still report deprecation warnings by default.

Once a developer actually starts configuring the warnings settings for their test runner explicitly, I figure how that interacts with the default settings is a question entirely for the developers of the particular test runner.

ncoghlan commented Nov 10, 2017

@merwok The only assumption we made at the interpreter level was that unconfigured test runners would be updated to still report deprecation warnings by default.

Once a developer actually starts configuring the warnings settings for their test runner explicitly, I figure how that interacts with the default settings is a question entirely for the developers of the particular test runner.

@nicoddemus

This comment has been minimized.

Show comment
Hide comment
Member

nicoddemus commented Dec 13, 2017

@nicoddemus

This comment has been minimized.

Show comment
Hide comment
@nicoddemus

nicoddemus Sep 6, 2018

Member

Closed by #3931

Member

nicoddemus commented Sep 6, 2018

Closed by #3931

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment