gh-118500: Add pdb support for zipapp#118501
Conversation
|
Hey @iritkatriel , this is something I always wanted to do and that's why I refactored the targets first. It turned out supporting zipapps is not that difficult at all. It basically just a special type of module and I followed the python interpreter to run the zipapp module in pdb. I added another type of target for |
| try: | ||
| _, self._spec, self._code = runpy._get_main_module_details() | ||
| except ImportError as e: | ||
| print(f"ImportError: {e}") |
There was a problem hiding this comment.
Why do you need to special-case ImportError here?
There was a problem hiding this comment.
That's from #108791. This is a very common case but the exception traceback would be very large because it's generated rather deeply and it distracts users. It would be a better experience to simply show that there's an import error when the user passes in an invalid module.
There was a problem hiding this comment.
Ok. there is also traceback.format_exception_only().
There was a problem hiding this comment.
Yeah I think the orignal thought here was just to suppress the common import error, and leave the others be. In that case we need a special case for ImportError anyway with or without format_exception_only.
|
When zipapp is being loaded, it seems to register the files in the zip to linecache so the other libraries can find the source. pdb can get the source file with no issue, the breakpoint mechanism needs a tweak, also not complicated.
Overall it worked without too much hassle.