Created attachment 131863 [details] Screenshot of wrong message SUMMARY STEPS TO REPRODUCE 1. Create a python virtualenv and activate it 2. Start kdevelop AppImage from this environment 3. Start a debugger on a project and try to browse a variable on a checkpoint OBSERVED RESULT The variable value displayed is: *** NameError: name '__kdevpython_debugger_utils' is not defined. EXPECTED RESULT One should see the variable value. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Operating System: KDE neon 5.19 KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.0 Kdevelop AppImage: KDE Frameworks 5.69.0 Qt 5.12.8 (construit sur 5.12.8) ADDITIONAL INFORMATION I cannot test that in the system's kdevelop because it crashes at me (issue opened).
Hi, KDevelop needs the system python runtime (i.e. the one with its utilities installed) for the debugger to work. You cannot start KDevelop from inside a python venv. Instead, configure the venv's python interpreter in your project settings. If the issue presists, please re-open this. Greetings!
I feel like we should be able to make this work though...
Hm, can you make python inside a venv import modules from outside that venv? Isn't part of the idea that this is not possible? ;) That is what we would need, I think. Either way, I'm not sure I agree that this should be possible. If the IDE was written in Python, you wouldn't expect that to be runnable from inside some random venv either, would you?
Well, I can accept that even if it seems natural for me to start my ide from a fully configured environment for the project. But in this case, there should be detection of the problem and a explicit message to the user. Here kdevelop is an AppImage. Does it include its python interpreter and the tools or does it depends on the system ones? In the latter case, I should be able to install the kdevelop system utilities in the venv, thus with pip or anything else. Finally, I tried, as you suggested, to start kdevelop from a clean environment with no venv and setting the venv python interpreter at the project settings level, but then the modules loaded in the venv cannot be found at runtime (debugger): ModuleNotFoundError: No module named 'torch' Is there other settings to do?
Does it work in "Run" mode? It's possible that the configured path is not used in "Debug" mode :/ The debugger is quite the stepchild of the whole thing ...
In fact, running and debugging both work with the correct setting. After setting the full path to my virtual env python interpreter in the "Configure project" dialog, I tried to run and debug while keeping just "python" as the "Script interpreter" in the "Launch configurations" dialog. And it failed like described above. After setting the full path to my virtual env python interpreter also in the "Script interpreter" in the "Launch configurations" dialog, it now works (running and debugging). My two conclusions/wishes: - when setting a full path to the python interpreter in the launch configuration, it should become the default one in the launch configs - there should be detection the start of kdevelop starting from a venv and a explicit message to the user stating that it should start from the system one
Created attachment 170782 [details] debugger_utils not defined
Comment on attachment 170782 [details] debugger_utils not defined Hello, I'm experiencing the same error, although I'm not using an AppImage, but the kdev-python package that comes with Debian 12 (Bookworm). My Python interpreter is set to /usr/bin/python3 I don't understand why the message '__kdevpython_debugger_utils' comes up when I hover over a variable while debugging. It works on the 'main' file, but for Python scripts that are imported (ie: from greet_file import Greet), the debugging shows that error in greet_file.
Here's how I can reproduce it. Save two Python files. 'start_here.py' and 'second_file.py'. #### start_here.py from second_file import Greet g = Greet("John") g.say_hi() #### second_file class Greet: def __init__(self, name: str): self.name = name <<-------Set a breakpoint here def say_hi(self): print("Hi there", self.name)
I've recorded a YouTube video which explains the issue in detail: https://youtu.be/VtxcojrpTwk Thank you!
Hi, thanks for this very detailed report. I've added the developer who has recently been working on the debugger to the CC list of this bug, maybe he knows something about this.
Additional info: I also tried installing Debian 12 in a virtual machine (clean install) and installed kdevelop-python with the same results. kdevelop-python is from Debian's package repositories (the one that comes with Debian 12), so now I know it's not just a bad installation on my end. Thanks again,
Thanks for the very nice bug report. :) The kdev-python's debugger is unfortunately quite broken, due to the in-band-communication not working well... So, until the debugger is resurrected, don't expect much. :-( E.g. There is a chance an sent command can fail receive it's response, and thus could lead to no detail for a variable. The kdevpdb can also fail to flush all of the commands, so they may fail to start running in timely manner. You can try select a stack frame manually to try unstuck the command processing. (Setting breakpoints while the program is running, is just asking for trouble at the moment, so I would avoid it. Set them all before launching to get least broken behavior.)
(In reply to JATothrim from comment #13) > Thanks for the very nice bug report. :) > > The kdev-python's debugger is unfortunately quite broken, due to the > in-band-communication not working well... So, until the debugger is > resurrected, don't expect much. :-( > > E.g. There is a chance an sent command can fail receive it's response, and > thus could lead to no detail for a variable. The kdevpdb can also fail to > flush all of the commands, so they may fail to start running in timely > manner. > > You can try select a stack frame manually to try unstuck the command > processing. (Setting breakpoints while the program is running, is just > asking for trouble at the moment, so I would avoid it. Set them all before > launching to get least broken behavior.) Thanks for the info. I look forward to a working kdev-python plugin; I think it has a lot of potential. If there comes a time a new version of the plugin needs to be tested, feel free to let me know. I'd be happy to try it out. Thanks again.
> Thanks for the info. > I look forward to a working kdev-python plugin; I think it has a lot of potential. > If there comes a time a new version of the plugin needs to be tested, feel free to let me know. > I'd be happy to try it out. That time would be now: https://invent.kde.org/kdevelop/kdev-python/-/tree/work/kdevpdb-ng This work branch basically contains a rewrite of the debugger. I welcome testing it. Note that, building this development version of kdev-python from source currently requires also building KDevelop master until KDevelop release/25.08 is out.