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

print captured logs before entering pdb #3210

Conversation

brianmaissy
Copy link
Contributor

@brianmaissy brianmaissy commented Feb 12, 2018

Fixes #3204. This is conceptually a continuation of #3186 but is not actually dependent on it.

@coveralls
Copy link

coveralls commented Feb 12, 2018

Coverage Status

Coverage increased (+0.03%) to 92.596% when pulling 9f3ea0e on brianmaissy:feature/added_printing_of_captured_logs_before_entering_pdb into 3bc8b50 on pytest-dev:features.

@@ -85,6 +85,12 @@ def _enter_pdb(node, excinfo, rep):
# for not completely clear reasons.
tw = node.config.pluginmanager.getplugin("terminalreporter")._tw
tw.line()

captured_logs = rep.caplog
if len(captured_logs) > 0:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should also check if live-logging is enabled here, in which case it does not make sense to print the captured logs again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mentioned this here #3204 (comment) as a continuation of our discussion with @nicoddemus on the other thread. I think it makes sense to print whatever we would have printed if we didn't enter pdb. If live logging is enabled, we print the logs when the happen and also in the report.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @brianmaissy that just printing them here is more consistent, but I don't have strong feeling either way to be honest.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thisch what do you think? If you agree we can merge this. 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can merge this. But I definitely want to change this "before entering pdb" behavior when capturing is off (-s) and/or live logging is enabled. I'll create a new issue for this with some screenshots.

Copy link
Member

@nicoddemus nicoddemus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @brianmaissy!

@brianmaissy brianmaissy force-pushed the feature/added_printing_of_captured_logs_before_entering_pdb branch from 65dbc4d to 069f32a Compare February 17, 2018 18:33
@brianmaissy
Copy link
Contributor Author

fixed merge conflict

Copy link
Member

@nicoddemus nicoddemus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As commented in #3204 (comment), we should really only output the logs if --no-print-logs is not set. 👍

@@ -97,6 +97,11 @@ def _enter_pdb(node, excinfo, rep):
tw.sep(">", "captured stderr")
tw.line(captured_stderr)

captured_logs = rep.caplog
if len(captured_logs) > 0:
tw.sep(">", "captured logs")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check the option inside the if block:

if len(captured_logs) > 0:
    if not config.getoption('no_print_logs'):
        tw.sep(">", "captured logs")
        tw.line(captured_logs)

Doing the alternative:

if len(captured_logs) > 0 and not config.getoption('no_print_logs'):

Is incorrect because it will raise if the logging plugin is disabled with -p no:logging.

Copy link
Member

@nicoddemus nicoddemus Feb 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which reminds me, we don't have a test to ensure pytest doesn't blow up if logging is disabled (-p no:logging), could you add one as well? Make sure to emit logging messages inside the sub-test, such a test would caught the error I mention above.

Copy link
Contributor Author

@brianmaissy brianmaissy Feb 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't they equivalent because of lazy boolean expression evaluation?
But in any case it's better to be explicit.

I encountered something strange though. If --no-print-logs is given, log_print is set to False. But if it is not given, it contains None, instead of True as I would expect. From a look at the code it seems like this is because default is not passed through to addoption. Is this intentional?

def add_option_ini(option, dest, default=None, type=None, **kwargs):
parser.addini(dest, default=default, type=type,
help='default value for ' + option)
group.addoption(option, dest=dest, **kwargs)
add_option_ini(
'--no-print-logs',
dest='log_print', action='store_const', const=False, default=True,
type='bool',
help='disable printing caught logs on failed tests.')

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yesterday I discovered that a --show-capture option has been added recently (see #3176). IMO this option should supersede the --no-print-logs option (see #3233 and #3234, where I removed the --no-print-logs option in favor of --show-capture). The PR #3234 is based on this PR. Please have a look at this PR and tell me what you think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. I'll wait until you merge #3234, and then I'll update this PR accordingly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I said in #3234 (comment), we should not really remove the --no-print-logs option, we should deprecate it first.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I guess that we don't need to use print_logs in debugging.py. We can use show_capture instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brianmaissy I guess that we can close this PR and merge #3234 instead, which contains your commit 069f32a.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good. do you want to take the test which checks with -p no:logging or a variation of it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we should add it there or in a new PR.

@brianmaissy brianmaissy force-pushed the feature/added_printing_of_captured_logs_before_entering_pdb branch 2 times, most recently from 0ddb029 to b1a74cb Compare February 18, 2018 21:30
@brianmaissy brianmaissy force-pushed the feature/added_printing_of_captured_logs_before_entering_pdb branch from b1a74cb to 9f3ea0e Compare February 18, 2018 21:34
@brianmaissy brianmaissy deleted the feature/added_printing_of_captured_logs_before_entering_pdb branch February 19, 2018 20:44
@nicoddemus
Copy link
Member

Thanks @brianmaissy for the implementation! 😁

twmr added a commit to twmr/pytest that referenced this pull request Feb 22, 2018
Implement the test from pytest-dev#3210, which was not merged yet, because the PR was
abandoned in favor or pytest-dev#3234.
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

4 participants