-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Implement CLI options to set truncation thresholds #12766
base: main
Are you sure you want to change the base?
Conversation
Thanks @zhukoff-pavel, we appreciate the PR! I would like to see what other maintainers think of this feature, overall I'm +1 on it, the only downside I see is the cognitive load of extra options... but perhaps others have different opinions here. I also wonder if this is better implemented as an ini option instead... seems like it would be more common to set this in the config file in test suites where this feature is often wanted (and of course it is always pass this using the |
@nicoddemus, thank you for your reply!
Maybe it is better to implement an Is it possible to implement such behaviour with current option reading machinery (with some combination of |
Your suggestion makes sense, however we have for awhile moved away from this because:
For this reason nowadays we prefer to have either a command-line option (for features where users are likely to change between pytest invocations) or an ini option (where users are most likely to set once per repository).
Unfortunately no, it requires duplicating the code. |
I see. Thank you for a quick reply! |
Thanks! I suggest to wait a bit in case some other maintainer has comments or reservations about the feature though. |
Been awhile and nobody seems to be against the idea, so feel free to go ahead. |
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @zhukoff-pavel!
Please take a look at my comments.
Co-authored-by: Bruno Oliveira <bruno@soliv.dev>
Co-authored-by: Bruno Oliveira <bruno@soliv.dev>
for more information, see https://pre-commit.ci
@nicoddemus , thank you for a thorough review! Please have a look at the changes. I implemented some logic regarding value of |
return explanation | ||
|
||
|
||
def _should_truncate_item(item: Item) -> bool: | ||
"""Whether or not this test item is eligible for truncation.""" | ||
verbose = item.config.get_verbosity(Config.VERBOSITY_ASSERTIONS) | ||
return verbose < 2 and not util.running_on_ci() | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite like how we are dealing with truncation_limit_lines
and truncation_limit_chars
in two places (even if they are next to each other)... feels error prone. 🤔
I think we should change _should_truncate_item
to return the max_chars
and max_lines
to use, and if it returns None
means "do no truncate"... if so we should also rename it, perhaps get_truncation_params
? This way only get_truncation_params
looks up at the options.
What do you think?
Btw this are all internal functions, so we are free to refactor them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I also did not like it when I implemented this, sounds good to refactor this place :)
Will think, what I can do here
However, I do think about return values here. None
sounds great, but will it be clear that it means "No truncation" instead of using default values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None sounds great, but will it be clear that it means "No truncation" instead of using default values?
You got a point, for a more visible API probably a new type would be best, but given this is internal and used in a single place, I guess using None
is fine (as long as if documented of course).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or perhaps it just makes sense to return (0, 0)
when it should not truncate at all? Whatever makes the logic handling in truncate_if_required
simpler.
@@ -549,6 +549,24 @@ captured output: | |||
By default, parametrized variants of skipped tests are grouped together if | |||
they share the same skip reason. You can use ``--no-fold-skipped`` to print each skipped test separately. | |||
|
|||
|
|||
Modifying truncation limits |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add a link target so we can refer to it from the CHANGELOG:
Modifying truncation limits | |
.. _truncation-params: | |
Modifying truncation limits |
@@ -0,0 +1 @@ | |||
Thresholds to trigger snippet truncation can now be set with :confval:`truncation_limit_lines` and :confval:`truncation_limit_chars`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thresholds to trigger snippet truncation can now be set with :confval:`truncation_limit_lines` and :confval:`truncation_limit_chars`. | |
Thresholds to trigger snippet truncation can now be set with :confval:`truncation_limit_lines` and :confval:`truncation_limit_chars`. | |
See :ref:`truncation-params` for more information. |
|
||
Modifying truncation limits | ||
-------------------------------------------------- | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.. versionadded: 8.4 | |
closes #12765
Example implementation of truncation limit setting with CLI flags