Exception stack trace not clickable in PyCharm

PyCharm suddenly changed the way it shows the stack trace on the run tab and does not let me click on the exception (or anywhere else) and go to the specific point of the error file anymore.

How can I fix this?

Running on OSX Sonoma, PyCharm 2022.2.3 (Community Edition)

The short answer: Eliminate all (direct or indirect) imports of the pretty_errors package.

The medium answer

If you use the torchmetrics package in your project, which tries to use pretty_errors, one of the following should work: (1) just uninstall the pretty_errors package from your Python environment, (2) update torchmetrics to a version that no longer uses pretty_errors (update: such as v1.5).

If you don't use torchmetrics, you might want to identify any other package that uses the pretty_errors package and eliminate the corresponding imports of pretty_errors.

The long answer

I had the same problem with exactly the same look and behavior of console outputs. In my case, I could trace it down to using the package torchmetrics in a project, which, in turn, imported the package pretty_errors. The pretty_errors package changes stack traces in the way that you experienced (compare screenshots on the project's site). And here is the corresponding code in torchmetrics/__init__.py where pretty_errors was imported (lines 17–18 in the source code):

if package_available("pretty_errors"):
    import pretty_errors  # noqa: F401

Once I commented out those lines locally, stack traces looked and behaved as usual again.

Above I wrote "was imported", because the current source code of torchmetrics does not use pretty_errors any longer – exactly for the reason that it makes stack traces arguably unusable – see corresponding pull request and commit on GitHub. So, at some point, probably the best solution is updating torchmetrics in your project. Update: By now, this should be possible with torchmetrics v1.5. For older versions, just uninstalling pretty_errors from your environment should do the trick. In particular, it won't break torchmetrics, since the import of pretty_errors is conditional there, anyway (see code snippet above).

If you don't use torchmetrics in your project, of course, then it must be another package that relies on pretty_errors, or you directly imported pretty_errors yourself. Identifying the culprit(s) shouldn't be that hard, and the corresponding solution should always be eliminating the use of pretty_errors.