-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Improve presentation of diagnostic errors using rich #10703
Improve presentation of diagnostic errors using rich #10703
Conversation
2624afb
to
e144173
Compare
2baace7
to
bf6b732
Compare
Ooops, I thought I'd opened this as a draft. Well, assuming the CI passes, this is ready for review! :) |
Just update
Seems like the behavior has changed here. But from the linting side, everything looks good 👍 |
Yea, that test is going to be non-trivial to update. The failure is basically because rich is smarter than pip's old logic about whether colours would make sense, and this breaks the assumption that the test was written with. I'm leaning toward redoing that test, to be |
Hurray! Ready for review now that I figured out how to make the test work on MacOS and Ubuntu. :) |
This was wrong and I'm glad that the test broke. I'd changed |
yield f"{self.message}\n" | ||
if self.context is not None: | ||
yield f"\n{self.context}\n" | ||
self.link = link |
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.
My hope is that, in the future, these can be generated using the reference
and somehow be synchronised with the documentation... but let's keep this as is for now. :)
3f4a835
to
cd8edc8
Compare
What are they now? (I didn’t read the change yet.) |
cd8edc8
to
c429c82
Compare
They were unstylized basically. I realised that this might not be ideal while we're transitioning over though, so I've gone ahead and readded the colours for this. |
c429c82
to
96b0ab1
Compare
d653e65
to
2009a22
Compare
Rebased, and should be good to review now! |
Good work, so much more readable than a wall of red! 🎨 |
Isn't using a pty in the test effectively re-testing Rich's own tested code? |
No. It's testing that the output respects pip's own |
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.
f strings with console markup is a bit of a gotcha with Rich. See escaping for details...
renderable = self.render_message(record, message) | ||
if record.levelno is not None: | ||
if record.levelno >= logging.ERROR: | ||
style = Style(color="red") |
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.
You might want to consider using Rich themes. That way you can define the styles in one place.
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.
Yea, I will probably do something like that in the future. For now, I want to keep this as a 1:1 replacement to avoid making/adding another indirection to think of while reviewing this.
Nudging @pypa/pip-committers for a review on this. :) |
Oh, and this is easiest to review commit-by-commit. The first commit is what makes the patch big. |
This doesn't really have any functional behaviour changes (i.e. it won't change what gets installed or stuff like that), so I am somewhat comfortable just merging this without having it go through a rigorous review from another maintainer. I'd still strongly prefer to get some more 👀 through this PR, in a manner similar to other PRs for #10421. |
Borrow error presentation logic from sphinx-theme-builder, and exhaustively test both the unicode and non-unicode presentation. Utilise rich for colours and presentation logic handling, with tests to ensure that colour degradation happens cleanly, and that the content is stylized exactly as expected. Catch diagnostic errors eagerly, and present them using rich. While this won't include the pretty presentation in user logs, those files will contain the entire traceback upto that line.
This makes it possible to present output with rich markup, within the constraints of our logging infrastructure. Further, diagnostic errors can now by presented using rich, using their own special "[present-diagnostic]" marker string, since those need to be handled differently from regular log messages and passed directly through to rich's console object, after an indentation wrapper.
The new name is a closer match with what is presented to the user.
This is only necessary on messages which may contain `[`, which needs to be escaped before printing with rich, since rich treats them as output formats.
This is necessary to ensure that the output can be compared directly.
Also, reflects that `--no-color` does not mean no-ansi-escapes but only affects colour rules.
This is a slightly cleaner presentation style.
7a0f28d
to
6b31f83
Compare
Indeed! Fixed both of those issues, which were both caused by mishandling in 7d4d84e. |
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.
Some minor suggestions.
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Going to go ahead and merge this now. If there's any concerns with this, please feel free to holler over at #10421! :) |
Toward #10421
Before:
After: