Repository navigation
Highlight my code vs framework code in tracebacks #522
Description
Originally reported by: Thomas Güttler (BitBucket: thomas-guettler, GitHub: thomas-guettler)
it would be very cool if pytest could highlight my code in tracebacks. This would make it much easier for the developers eyes to find the buggy code line.
In 98% percent of all tracebacks I get, the bug is in my code, not in one of the many external libraries.
Of course it needs some kind of heuristic to decide if a traceback line is from my code or from a library/framework.
Some time ago this was implemented in django, and I liked it very much: You find the important code lines much faster. Since we changed your development style to test driven development, we don't see django tracebacks any more. We use pytest now.
See https://code.djangoproject.com/ticket/11834
This is a feature request. My pytest knowledge is not very good. I think someone else would be much faster.
Which steps should be done to implement this?
Activity
Zac-HD commentedon Oct 20, 2018
I'm closing this issue for two reasons: it's been inactive for four years, but more importantly this kind of traceback management is something that has to be done upstream in frameworks if we're to have any hope of getting it right - and deleting the wrong parts of tracebacks is really really bad for users. For example, both Trio and Hypothesis have recently started trimming their internals from user-facing tracebacks.
(I distinguish here between a "library" which is called by your code, and a "framework" with calls your code. There is no general way to shorten library tracebacks without making them less useful, even upstream.)
RonnyPfannschmidt commentedon Oct 20, 2018
I disagree, in particular ssince there days we can partition by distribution
blueyed commentedon Apr 8, 2019
@RonnyPfannschmidt
Some input on your idea would be good, since I've started looking into this already (with recent improvements to terminal representation).
RonnyPfannschmidt commentedon Apr 13, 2019
@blueyed basically trace-back sections should be collapsed by "distribution" - so sqlalchemy/django/... dont dig in deeper than necessary unless asked for, alternative ux systems could have expand/collapse buttons to view those (like html)
blueyed commentedon Apr 13, 2019
Ok. But how to determine which distribution a traceback entry belongs to? Base on the frame's filename only, or is there something more meta in there?
And how to know the "current"/"main" distribution, i.e. the project itself?
RonnyPfannschmidt commentedon Apr 13, 2019
current can only reliably be known if its a editable install roughly matching the testdir
distribution metadata has records about belonging files
pfctdayelise commentedon May 1, 2019
I think this is the same idea as #283.
akx commentedon Feb 7, 2020
Any activity on this? I think a hook for categorizing stack frames would be a nice start (á la #283 (comment)).
I'd further elaborate on that by allowing the hook to return a freeform dict of tags that reporters could use as they'd like, maybe something like
with multiple hooks' retvals merged together.
A more elaborate/built-in implementation could attempt looking at distribution metadata too...
blueyed commentedon Feb 7, 2020
@akx good idea!
Related: #6658 (highlighting of source code in tracebacks).
RonnyPfannschmidt commentedon Oct 18, 2023
closing as duplicate of #283