-
Notifications
You must be signed in to change notification settings - Fork 160
Support pyqt6 #1112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
If you enable Also, can you try with If it still happens with the See: https://github.com/microsoft/debugpy/wiki/Enable-debugger-logs for details on how to collect the logs. |
With the following code I do get a stacktrace:
Stack trace
It seems to still happen. I'm not sure which log is necessary? Here are the ones generated after running and crashing. debugger.vscode_5a0785b7-36ab-4aac-964d-2a96be337842.log |
Something I realized may not have been clear: Running the code works fine, and any breakpoint or stop before importing matplotlib works fine. Breaking at/before the import, then continue the run works just fine, and the code executes. But any "stop" (from a breakpoint, or stepover) after the matplotlib import creates the segfault. |
Thanks,
So, the real issue is that it's trying to activate qt5 (so, I guess you have both qt6 and qt5 installed) and when it does that qt crashes. One thing here is that the debugger doesn't currently support qt6 (I'll rename this issue accordingly). In the meanwhile, you should be able to set:
in your launch configuration to avoid the crash. -- note: this will mean that graphs you create won't be interactive when you're stopped in a breakpoint until qt6 is actually supported -- at which point you should be able to remove that |
Ah I see. Indeed, when installing
So PyQt 5.15 ann PyQt5-sip 12.11. Installing The takeaway I get from that is that, more than support for PyQt6, it's the presence of both pyqt6* packages along with pyqt v5 and pyqt5* packages that is problematic. I guess this is expected beyond debugpy. So either making sure I only have PyQt6 (thus no Thank you for your kind help! |
I am wondering, is the problem the qt_loaders file or is there something more? Sorry for my ignorance but I don't know how debugpy works inside |
It's also the input hooks in the same package - that's the part that works with matplotlib. |
Ok, thank you, I thought so, it is a shame it is not included PySide6. Do you know if it is in the planning to make it compatible at some point? |
It's on the backlog now, but with no specific schedule. Generally speaking, when it comes to features, the ones that are in higher demand (as evidenced by e.g. GitHub upvotes) are scheduled to be implemented first. |
I have the same. I worked around it by deleting the PyQt5 folder. |
What do you mean? In the debugpy installation folder? |
Thank you for the report. Given our current resources are working on the Python 3.12 debugger, we will not be fixing this issues in the pre Python 3.12 debugger. |
From my site-packages folder. |
Since v1.8.1 now supports Python 3.12, would you consider reopening this issue? |
To clarify, by "pre-Python 3.12 debugger" we mean not support for a particular Python version, but the use of the new debugging APIs introduced in Python 3.12. While the most recent stable debugpy release supports Python 3.12, its overall architecture is still based on legacy Python APIs, and we are not heavily investing into that codebase at this point. |
Environment data
Actual behavior
The debugger just "stops" after importing matplotlib, with no sign or crash or error. Just seems to be complete. See the screencast at the end.
Expected behavior
Debugging continues to the next line
Steps to reproduce:
To make it easier, here are the minimal reproducible example I could generate:
Open VS Code, create a file, enter the following content
Put the breakpoint, start debugging, step over.
Additional information
It seems removing either of matplotlib, jupyter or PyQt6 solves the problem.
Installing an older version of the Python extension (ms-python.python) also works. v2022.4.1 was the first that caused the issue, while the previous (previous according to VS Code) v2022.2.1924087327 still works.
I could capture the behavior in the following video:
screencast.webm
The text was updated successfully, but these errors were encountered: