By default, provide a much more concise error message. #4985
Conversation
|
This PR creates a much nicer experience for users who are actively developing their unstable projects and are working through compiler issues. Lots of open questions: What's the right tradeoff between user-caused errors and internal errors? My instinct is that build_editable has been stable for a while now, so Setuptools can shift the burden to assume the error is on the user's side. Should the code provide an escape hatch to get more detail? If so, what is the mechanism (environment variable, configuration setting like verbosity or debug, or something else)? Is |
There was a problem hiding this comment.
Pull Request Overview
Aims to provide a more concise error message during editable wheel builds by conditionally printing the traceback only when internal debugging is enabled.
- Removed unconditional traceback printing in favor of a conditional check on the environment variable
- Replaced verbose traceback output with a concise error message when not debugging
| traceback.print_exc() | ||
| _DebuggingTips.emit(project=project) | ||
| else: | ||
| print("An error occurred building editable wheel for", project) |
There was a problem hiding this comment.
Consider using a logging mechanism (e.g., _logger.error) instead of print to ensure the error message is sent to the appropriate error stream and is consistently captured in the logs.
| print("An error occurred building editable wheel for", project) | |
| _logger.error("An error occurred building editable wheel for %s", project) |
Copilot uses AI. Check for mistakes.
There was a problem hiding this comment.
Thank you very much @jaraco.
The ideal solution for me would be something like:
-
Move the debugging tips text from the
_DebuggingTipsclass to thedocs/userguide/development_mode.rst(and remove the class). -
Use something like:
try: ... except Exception as ex: ex.add_note( f"An error occurred when building editable wheel for {project}.\n" "See debugging tips in: " "https://setuptools.pypa.io/en/latest/userguide/development_mode.html#debugging-tips" ) raise
I think that would be a fine approach. However it depends on PEP 678 behaviour, which is implemented in 3.11 and is not trivial to backport.
So I think we have a couple of options:
- Simply remove the whole
try...except...wrapper and let the method crash and bypass the complexity ofadd_notebackporting. - Implement something in
compat.py311.add_note:
2a. We can simply assign the__notes__to the exception, and optimistically hope that frontends use something likerichwhich reads__notes__regardless of the python version to render exceptions instead of using Python's default exception printing12
2b. Use something simple likeprint(...)as used in this PR, orwarnings.warn(...)orlogging.warningas an imperfect replacement foradd_note.
2c. Implement a more complete backport by assigning__notes__and adding a customsys.excepthookto ensure they are printed even in Python 3.10. This may be non trivial because of the details and the cases where other packages are already customisingsys.excepthook.
To be honest, I don't see much of a problem with option 1 or 2a.
Footnotes
-
For Python <= 3.10, the default exception display mechanism will ignore
__notes__. ↩
Fixes #4984
Summary of changes
Closes
Pull Request Checklist
newsfragments/.(See documentation for details)