-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Fine grain output verbosity #11387
Comments
Started working on this and unsurprisingly realized that how General SummaryThe vast majority of uses of the verbose setting are within _pytest.terminal. In addition to using it directly,
Uses of
|
That reference is helpful to understand what things accessing verbosity and how. But it's not the easiest to understand the full behavior. So I went through and documented the behavior by verbosity level. (This helped me get a better understanding of specific aspects that can be controlled.) -2
-1
0
1
2
|
I completely missed |
Should this really have been closed, since (from what I can gather) only a small part of the proposal is implemented so far? |
True! |
What's the problem this feature will solve?
There are multiple open issues that are requesting more control over the output displayed by
pytest
.--verbose
turns everything up, but it would be nice to be able to just increase or decrease the verbosity for specific aspects of the output.Open issues that I've found that fit into this problem space (there may be others):
-v
mode, still display full value in-vv
#5285Describe the solution you'd like
I think a way that could resolve all of these is to add an abstraction layer on top
config.option.verbose
. Rough pseudo-code example:For general cases, the
verbose
attribute could be used. For special cases, an output type name could be passed in retrieve the more fine grained setting. If the specific config is not set, it will default to the normal verbose level. Once this is in place, it would be easier to add more cases in the future if they come up.Implementation
verbosity_{OUTPUT_TYPE}
seems reasonable to me.The text was updated successfully, but these errors were encountered: