Limit traceback to one entry by default

[EpicWink]

What's the problem this feature will solve?

Large and unnecessary tracebacks in user bug-reports

Describe the solution you'd like

Set the trace-back limit sys.tracebacklimit to 1 by default. Don't set when verbose-logging (ie -vv passed at command-line). This includes build-backend subprocesses (in the vendored pep517 subprocess), but not when using an in-tree build-backend.

Alternative Solutions

None

Additional context

None

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

[pradyunsg]

I don't think they are unnecessary by any means. And, making the build-backend process fail gracefully is the responsibility of the build backend -- pip shouldn't be trying to cooerce their output to be shorter and potentially make it more difficult for the authors to diagnose issues.

[EpicWink]

I think showing a traceback for expected failures confuses the user; example. I don't think it's reasonable for pip's authors to catch all known-possible exceptions and convert them to simple errors.

I think having the line of code which raises the exception in the bug-report is useful, allowing the maintainer to see where a fix needs to be applied. Ideally this would be the most inner line of code of pip or the build backend, but that is a little more complicated to implement. Perhaps tracebacklimit = 3 would cover most cases.

I can agree that leaving the error output up to the build backend makes sense, perhaps there should be some mechanism (cough config_settings) to send the user's current verbosity settings to the backend.

In any case, -vv would enable the whole traceback, and you can ask the user to re-run the install with this in the bug-report template.

[pradyunsg]

Well, I think that is a case where we should update pip's presentation of errors and improve how we handle errors in the TOML file. I'll add a x-ref to #10421, for which this is a great candidate. Improving exactly this errors is on my TODO list of that effort, which I expect to come back to in the coming weeks.

[pfmoore]

Specifically with regard to build backend output, backends can write arbitrary output to stdout. Pip captures this, but doesn't parse it (we can't!) so we only have the option to display or not display. Not displaying backend errors would make it impossible for the user[^1] to know what happened. Now that we use rich for our output, maybe we could report the backend output in a different manner, to emphasise that it's supporting information (a lower-contrast colour, for example?)

[^1]: And even more importantly, if the user can't work out what's going on, the people the user goes to for help - who might well be capable of analysing the traceback.

[pradyunsg]

FWIW, I do agree that we should be presenting our internal errors differently though. Something like rich's tracebacks could make sense for that. I have a draft patch somewhere, adding rich tracebacks and a PIP_RICH_TRACEBACKS=0, pip --no-rich-tracebacks.