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

Implement CLI options to set truncation thresholds #12766

Open
wants to merge 20 commits into
base: main
Choose a base branch
from

Conversation

zhukoff-pavel
Copy link

@zhukoff-pavel zhukoff-pavel commented Sep 2, 2024

closes #12765

Example implementation of truncation limit setting with CLI flags

@psf-chronographer psf-chronographer bot added the bot:chronographer:provided (automation) changelog entry is part of PR label Sep 2, 2024
@zhukoff-pavel zhukoff-pavel marked this pull request as ready for review September 2, 2024 18:48
@nicoddemus
Copy link
Member

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 -o option in the command line).

@zhukoff-pavel
Copy link
Author

@nicoddemus, thank you for your reply!

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 -o option in the command line).

Maybe it is better to implement an .ini option and CLI flag to e.g. temporarily override limits in a singular launch?

Is it possible to implement such behaviour with current option reading machinery (with some combination of addoption and addini methods)?

@nicoddemus
Copy link
Member

nicoddemus commented Sep 9, 2024

Maybe it is better to implement an .ini option and CLI flag to e.g. temporarily override limits in a singular launch?

Your suggestion makes sense, however we have for awhile moved away from this because:

  1. It involves a lot of code duplication
  2. We have mechanisms today where users can use them interchangeably (use addopts to hard-code command-line options in the ini file, and use -o to pass config options in the command line).

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).

Is it possible to implement such behaviour with current option reading machinery (with some combination of addoption and addini methods)?

Unfortunately no, it requires duplicating the code.

@zhukoff-pavel
Copy link
Author

zhukoff-pavel commented Sep 9, 2024

I see.
I can then rewrite this PR to implement .ini option instead, as it definitely looks more like a one-time config setting rather than per launch.

Thank you for a quick reply!

@nicoddemus
Copy link
Member

I can then rewrite this PR to implement .ini option instead

Thanks! I suggest to wait a bit in case some other maintainer has comments or reservations about the feature though.

@nicoddemus
Copy link
Member

Been awhile and nobody seems to be against the idea, so feel free to go ahead.

@zhukoff-pavel zhukoff-pavel marked this pull request as draft September 16, 2024 16:39
@zhukoff-pavel zhukoff-pavel marked this pull request as ready for review September 16, 2024 16:51
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 @zhukoff-pavel!

Please take a look at my comments.

changelog/12765.feature.rst Outdated Show resolved Hide resolved
doc/en/how-to/output.rst Outdated Show resolved Hide resolved
src/_pytest/assertion/truncate.py Show resolved Hide resolved
testing/test_assertion.py Outdated Show resolved Hide resolved
@zhukoff-pavel zhukoff-pavel marked this pull request as draft September 16, 2024 20:11
@zhukoff-pavel zhukoff-pavel marked this pull request as ready for review September 16, 2024 21:14
@zhukoff-pavel
Copy link
Author

@nicoddemus , thank you for a thorough review!

Please have a look at the changes.

I implemented some logic regarding value of 0 being set in one mode or both at a time.

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()

Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

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).

Copy link
Member

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
Copy link
Member

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:

Suggested change
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`.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
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
--------------------------------------------------

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
.. versionadded: 8.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bot:chronographer:provided (automation) changelog entry is part of PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Customisable truncation limits
2 participants