Hi!
I’m happy to announce the the availability of version 1.5 of kdev-python, the Python language support plugin for the KDevelop development environment. For the official (short) announcement containing links to the tarballs, see the announcement on the KDevelop website.
Here’s a short video which demonstrates some of kdev-python’s (and KDevelop’s) nice features:
(if your network connection allows it, you can also watch the full-resolution version — or here’s a link to the youtube version if the embedded one doesn’t work)
If you prefer a written summary of features and changes, please refer to the kdev-python 1.4 announcement and to the what’s new in kdev-python 1.5 post.
I probably have written it often enough, but I’ll repeat it once more: Python 3 support in kdev-python will be released together with Python 3.4.
Another note, if you’re using master, you have to clear your build directory (this includes running make clean in python-src/) to make it build again due to changes in the build system. If you didn’t do any changes yourself, you can also run “cd kdev-python; git clean -f”. Be aware that this will delete all untracked files in the kdev-python directory.
Categories: Everything
Tags: kdev-python, kdevelop, planetkde, release, stable
Great job! Thanks a million for this awesome work you do!
Congrats on the release!
…and nice video 😀
Make sure you have "Output Filter: Script Error Filter" set in the launch configuration (Run -> Configure launches)". Then it should just work. You can then configure the shortcut as always, via Settings -> Configure shortcuts.
Awesome! Great work!
Thank you VERY MUCH for a great tool!
great! keep it up!
Dude thanks for the great job but still – where can i find what is going on AFTER i install it, the installation goes great but after that i'm like, expecting to find this in 'Loaded plugins' you know.
Look at where cmake installs things — this is what you pass it as -DCMAKE_INSTALL_PREFIX=/some/directory. If /some/directory is your default KDE installation directory (/usr on many distributions) you can just run "kbuildsycoca4" (or just "kbuildsycoca" on some systems) and restart KDevelop; otherwise, run export KDEDIRS=$KDEDIRS:/some/directory, then kbuildsycoca, and then restart KDevelop.
Either way, doesn't your distribution have packages for kdevelop and kdev-python? Quite a few distributions have them already.
I'm using fedora 17 but i installed KDevelop 4.5 in 2012 … So one solution would be reinstall… Thanks for the fast answer, there is a problem with kbuildsycoca4 ( XDG standard (missing trailing semicolon ) but still it means kdevelop should load the plugin from somewhere. Yes my default KDEDIRS is /usr (echo $KDEDIRS said so) but the problem is in kbuildsycoca4 execution … I'll try with reinstall 😀
Those are just warnings, you can probably ignore them. The question is, where did you install the plugin?
Also KDevelop 4.5 was only released in 2013 so I doubt you have installed it in 2012…
Hmm probably you are right that i moved from 4.4 to 4.5 in 2013 … However its 4.5 now, i read the install_manifest.txt . It always starts with
/user/local but i'll paste this one just for sure :
/usr/local/lib/libkdev4pythonparser.so
Then i added /usr/local to KDEDIRS, executed kbuildsycoca4, and started kdevelop from this same terminal. And it works, in the 'Loaded plugins' i see Python support and Python debugger. I guess my default inst dir wasn't /usr … Great job once again, i didn't wanted to switch to another IDE 🙂
Yes, if you don't specify a directory it'll often be installed in /usr/local instead of /usr, so you need to add that. Glad it works now. 😉
Great job!!!
I am new with kdevelop. One question, how can i use a virtualenv for django project??? thanks.
I never did that, so I fear you're pretty much on your own here.
KDevelop will use the paths from the standard python interpreter "/usr/bin/env python" for processing. If you change KDevelop's idea of what that runs, it'll run with different packages.
You can also change the $PYTHONPATH environment variable to get different paths.
I have just installed KDevelop 4.5.1 and kdev-python 1.5.1 on Kubuntu 13.10.
I have been wanting to use KDevelop for the longest time and now that it has Python support, I thought I'd bring in my Python game.
Project -> Open / Import Project doesn't work for me because I only have .py files and it was looking for .kdev4, makefiles, or a CMakeLists.txt.
So I did Project -> New from Template and chose Simple Python Application and set the Location to my existing .py directory.
So far so good.
Then it took me some fiddling to get my existing Python project to execute because I realized that the "Simple Python Application" wasn't filling in the "Launch Configurations". So after I did that with my best guesses, I could execute my game, but I could not debug it. Nothing happened. And I was really looking forward to using the step-trace debugger….
In Run -> Configure Launches, under Global and clicking on the Debug tree item, the Debugger drop-down menu item in the upper right-hand corner only contains GDB; there is no other option. And none of the line edit fields have any values, which lead me to put in pdb for "Debugger executable", yet that doesn't work.
If I go to Settings -> Configure KDevelop -> Plugins, I see that kdevpdb is checked, although clicking on its "i" icon doesn't tell me how to use it (grrr! all plugins should be self-documenting, no matter where they show up in the KDE ecosystem).
Can you tell me where can I find documentation on how to configure this powerful system so that I can interactively debug my Python programs? Thank you!
Hi!
First of all, you can open folders as projects. Just select your project folder and click Open; the option to select CMakeLists.txt or similar files is just a bonus which does some extra things for C++ (such as configuring include paths automatically).
For launching python apps, make sure you use the Script Application Launcher, not the Native one. Otherwise debugging won't work. I'm not sure if kdev 4.5 still has this horrible old launch configuration dialog (in that one you have to scroll horizontally in the left treeview to find the place where you can change the launcher type), in the new one it should be quite obvious how to do it.
Greetings,
Sven
Hello and thank you!
"First of all, you can open folders as projects. Just select your project folder and click Open…"
Ah, okay. That wasn't clear before, but I just tried it with a test folder and that would've been easier had I known before.
"…make sure you use the Script Application Launcher, not the Native one."
Oh! That made all the difference! Debugging now works 🙂
"I'm not sure if kdev 4.5 still has this horrible old launch configuration dialog (in that one you have to scroll horizontally in the left treeview to find the place where you can change the launcher type),…"
What I'm seeing is an "Add New" button that drops down a menu with 3 choices, one of them "Script Application". So that's it 🙂
The option that was tripping me up was that of the 3 choices, there was one that simply said "Application". Well, that's not very descriptive. I considered my Python program an "application", although it's really a "Script Application" by the author of this part of KDevelop.
For clarity, maybe instead of "Application" it could be "Compiled Binary Executable" and "Script Application" could be "Script Interpreter"? That would've been more clear to me.
Thanks again!
Yes just yesterday I was considering that this choice of naming is probably confusing. The problem is that you need the balance between "technically correct" and "understood by people" 😉
Probably the "Application" should really be "Compiled binary" or so, although it's not correct since it can launch everything the Linux kernel can launch, i.e. binaries but also scripts with +x and a shebang line. But for the latter you want to use the Script launcher anyways… so I guess it should be changed.
Maybe it would even make sense to have a dedicated "Python script" entry.
Yes, a dedicated "Python script" entry would be great.
I could figure out most everything else when bringing my project into KDevelop, even if the project import aspect was a bit rough at first. But if this one little detail could be made more understandable, it would go a long way to creating a smooth entry for someone who's new to the KDevelop environment.