Highlight my code vs framework code in tracebacks

[pytestbot]

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?

---

• Bitbucket: https://bitbucket.org/pytest-dev/pytest/issue/522

[Zac-HD]

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]

I disagree, in particular ssince there days we can partition by distribution

[blueyed]

@RonnyPfannschmidt
Some input on your idea would be good, since I've started looking into this already (with recent improvements to terminal representation).

[RonnyPfannschmidt]

@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]

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]

current can only reliably be known if its a editable install roughly matching the testdir

distribution metadata has records about belonging files

[pfctdayelise]

I think this is the same idea as #283.

[akx]

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

def pytest_tag_traceback_entry(traceback_entry: TracebackEntry) -> Optional[dict]:
   if '/django/' in traceback_entry.path:
       return {'package': 'django'}
   return None  # this hook doesn't know how to categorize this

with multiple hooks' retvals merged together.

A more elaborate/built-in implementation could attempt looking at distribution metadata too...

[blueyed]

@akx good idea!
Related: #6658 (highlighting of source code in tracebacks).

[RonnyPfannschmidt]

closing as duplicate of #283