✨ Suppress modules in Rich tracebacks with pretty_exceptions_suppress#1498
✨ Suppress modules in Rich tracebacks with pretty_exceptions_suppress#1498harkabeeparolus wants to merge 14 commits intofastapi:masterfrom
pretty_exceptions_suppress#1498Conversation
📝 Docs previewLast commit a2f39df at: https://bbb0094b.typertiangolo.pages.dev Modified Pages |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
# Conflicts: # typer/main.py
This comment was marked as resolved.
This comment was marked as resolved.
…_suppress # Conflicts: # typer/main.py # typer/models.py
This comment was marked as resolved.
This comment was marked as resolved.
|
Thanks @harkabeeparolus! I'll try to review this week or the next 🙏 |
pretty_exceptions_suppress
svlandeg
left a comment
There was a problem hiding this comment.
Thanks for the PR!
I think the feature request in itself might make sense, though I'd have to double check with Tiangolo whether he'd want this or not.
Unfortunately the implementation in this PR is not good enough, as it uses a mock-up lib that users won't have in their env, and the test is not actually functional.
|
|
||
| ## Disable Tracebacks From Certain Modules | ||
|
|
||
| If you are developing with Python frameworks other than **Typer** and **Click**, |
There was a problem hiding this comment.
As we'll be vendoring Click in the near future, I suggest to not include the reference here.
| If you are developing with Python frameworks other than **Typer** and **Click**, | |
| If you are developing with other Python frameworks besides **Typer**, |
| @@ -0,0 +1,18 @@ | |||
| import gitlab | |||
There was a problem hiding this comment.
I see that you're mocking the installation of gitlab for this to run in the test suite.
What I dislike about using gitlab as an example here, is that users reading the tutorial would have to install the lib just to replicate this one example.
Is there a different example, with already installed libraries, you can think of to showcase this functionality?
|
|
||
| </div> | ||
|
|
||
| ## Disable Tracebacks From Certain Modules |
There was a problem hiding this comment.
Similar to the other sections in this part of the tutorial, this section should show the output before and after setting this new var.
|
|
||
| # This will raise an exception if not authenticated: | ||
| # GitlabAuthenticationError: 401: 401 Unauthorized | ||
| # But the traceback will not show any lines from the gitlab module! |
There was a problem hiding this comment.
In general we tend to avoid comments in the source files, as they are displayed verbatim in the tutorial, which should have all the relevant information.
| # This will raise an exception if not authenticated: | |
| # GitlabAuthenticationError: 401: 401 Unauthorized | |
| # But the traceback will not show any lines from the gitlab module! |
| _gitlab.__file__ = "gitlab/__init__.py" # type: ignore[attr-defined] | ||
| sys.modules.setdefault("gitlab", _gitlab) | ||
|
|
||
| from docs_src.exceptions import tutorial005_py310 as mod # noqa: E402 |
There was a problem hiding this comment.
There's no need for noqa: E402 here, just move the import to the top of the file.
| # that the tutorial code runs without errors. | ||
|
|
||
| # Perhaps we could find some standard library module that throws a long | ||
| # traceback and test that instead, but for now this is probably good enough. |
There was a problem hiding this comment.
I'm afraid I disagree - this test doesn't actually test anything. What should get tested, is whether or not the traceback is suppressed. Switching to an actual lib that is in the environment (instead of doing all this mocking) would probably resolve that.
|
Thank you for the review! @svlandeg I see your point about not testing the actual suppression of traceback content. I thought that since this is a standard Rich feature, we'd effectively be testing whether internal Rich features are working or not. And I thought that would be Rich's responsibility. However, since Typer de facto breaks this standard Rich feature (by overriding it), it would make sense to test what actually happens to the end user. Fair enough. 😊 I'll try to Google or brainstorm some kind of scenario with a long traceback stack through the Python standard library, I guess. 🤔 |
|
I think I found a good use case, with only Python standard library modules. With an unknown URL protocol you get five (!) stack frames from Try this one with and without my PR, to really see how much mess the default Rich traceback formatter normally can remove in these scenarios: import urllib.request
import typer
app = typer.Typer(pretty_exceptions_suppress=[urllib.request])
@app.command()
def main():
urllib.request.urlopen("unknown://example.com")
app()I'll look into updating my PR with this scenario instead of python-gitlab in the next few days, so we can actually test the business logic. And add a before-and-after that could be used to frighten small children. 😱 I think it'll be an improvement. |
|
Sounds great! |
It would be useful to provide our users with the Rich traceback suppress parameter. This would allow developers to suppress uninteresting stack frames in tracebacks from other Python frameworks.
For example,
python-github, which gives a verbose traceback with many frames on a simpleGitlabAuthenticationError. I would like to be able to suppress this entire call stack, but it doesn't work:But with this pull request, you can suppress modules directly with
Typer():