Red Hat Bugzilla – Bug 972474
[abrt] eclipse-pydev-2.7.1-6.fc17: pydev_imports.py:26:<module>:ImportError: No module named queue
Last modified: 2013-07-19 04:28:35 EDT
Version-Release number of selected component:
cmdline: /usr/bin/python2.7 -u /usr/share/eclipse/dropins/pydev/eclipse/plugins/org.python.pydev_184.108.40.2062100913/pysrc/pydevd.py --vm_type python --client 127.0.0.1 --port 54330 --file /usr/share/eclipse/dropins/pydev/eclipse/plugins/org.python.pydev_220.127.116.112100913/pysrc/runfiles.py /home/vehre/rpmbuild/duplicity --port 51964 --verbosity 0
Created attachment 758860 [details]
Created attachment 758862 [details]
Created attachment 758863 [details]
Neil, please investigate whether this is reproducible with pydev master?
Andre, could you provide a reproducer please?
As far as I can tell, I can't reproduce this error with master. I'm able to run modules without getting any import error from pydevd's import of pydev_imports. Also, when I remove 'import pydev_imports' from pydevd.py it _does_ raise an error, so I at least know it's being imported when it's working correctly.
If you think there's something I'm missing, please notify me and I'll test some more.
Ok, I managed to reproduce the error. I am giving a howto based on the source of duplicity available from: ftp://sunsite.informatik.rwth-aachen.de/pub/comp/Linux/fedora/linux/updates/17/SRPMS/duplicity-0.6.21-1.fc17.src.rpm (replace with your preferred mirror).
1. Unpack the src.rpm and the tar.gz inside it.
2. In eclipse create a new pydev project and import the source of duplicity into it.
3. Make the project a pydev one.
4. In the project settings modify the PYTHONPATH to include the duplicity-folder containing the python-files (in the source-tgz this folder is called duplicity).
(see picture pythonpath.png attached).
5. Configure a debug-configuration like in the picture debug.png. (no arguments, just try to start duplicity).
6. Click on debug in the configuration dialog.
7. I reproducible get this error:
Traceback (most recent call last):
File "/usr/share/eclipse/dropins/pydev/eclipse/plugins/org.python.pydev_18.104.22.1682100913/pysrc/pydevd.py", line 3, in <module>
File "/usr/share/eclipse/dropins/pydev/eclipse/plugins/org.python.pydev_22.214.171.1242100913/pysrc/pydev_imports.py", line 26, in <module>
import queue as Queue #@UnresolvedImport
ImportError: No module named queue
and a crash report.
I hope this helps. Btw, my F17 is fully up2date.
Created attachment 767445 [details]
Picture of the python path settings.
Created attachment 767446 [details]
Configuration used for debugging to produce the crash.
Thank you very much for the help. I set up a project like you said, and I get the same error you do when I debug. I'll now examine the issue.
May be it helps to know, that duplicity has pydev-debugging support integrated. I think I saw a line in the scripts/duplicity python module, where the pydev debugger is called.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Have you ever been able to run duplicity in Eclipse-PyDev before? I ask because running and debugging duplicity with PyDev always crashes _very_ early on, and on simple things like imports that don't cause errors when running other scripts, leading me to think that maybe there's a problem with running duplicity with Eclipse in general. (I'm able to run duplicity normally in Terminal, but never in Eclipse without an error, with or without arguments.)
Eclipse is also unable to resolve several imports by duplicity files (I get 50 "undefined variable from import" errors), and in many cases I can't find the required components myself. Is there something else I have to install, or to include in my project folder?
I should also mention that I get different errors for running and debugging duplicity; debugging gives me the Queue import error, while running crashes when /bin/duplicity tries to import things. (And since I updated to F19, I get an error on trying to import collections.namedtuple.) Debugging also causes a dialogue to pop up, telling me that there was an "Unexpected error setting up the debugger". And when I try commenting out the queue import (in pydev_imports) to see how far the script will get, it crashes on other imports, until it fails importing something from the core Python library in root.
Do these kinds of errors happen with different scripts than duplicity?
Thanks for your help.
I haven't forgotten you. But, because of end of lifetime of f17, I upgraded to f19 and had to win the battle with eclipse (Kepler). I now managed to set things up again.
To your questions:
- No I have never been able to run duplicity in eclipse-pydev before. The issue with duplicity may be, that it is used by deja-dup and called by it. Deja-dup is a vala program. I think, that because of this in duplicity is a way to hook up to pydev debugging, but I haven't figured out how yet.
- The many unresolved symbols may stem from a strange way of python including the glib functionality. But this is just my guess, I am not sure about it. Duplicity can use several backends, where not all are supported in fedora directly. This may also cause some unresolved symbols. But nevertheless, when these backends are not instantiated, then debugging should be possible.
- No, I encountered this strange behavior only with duplicity. Other scripts ran fine.
Okay, good to hear! Thanks for the info. Do you get significantly different errors when using F19? I still get import errors since I upgraded, but the things that can't be imported are different.
I'm going to look up other complex python scripts/programs to run with PyDev, and see if they suffer from similar problems.
Im my opinion the errors changed a bit from f17 to f19. I am now trying to figure out, how duplicity is to be debuged with pydev, because I encounter another error now (from duplicity). Once I find out, I will let you know. May be this help improving pydev.
I am able now to start duplicity in pydev. It was a real fight. Hopefully I remember everything that needs to be done:
(duplicity sometimes abbreviated by dup)
1. Remove any system installed duplicity using "rpm -e --nodeps duplicity" as root, because else the dup to debug will take file from the system installation.
2. From above description remove item 4, i.e., do NOT add the duplicity-folder to the PYTHONPATH in the project. Just use the system path with no adds. Having the path to dup in the PYTHONPATH gives the error, that _queue can not be found in collections.py, because dup has its own file collections.py, which does not contain a class queue, but the threading module of the system desires the system's collections.py. This fixes the error of this report.
3. Still in the project properties go to the builders and add a custom builder to call "dist/setup.py build". This will generate a new folder build with three sub folders. scripts-2.7/ lib..../ and temp..../
4. Edit the source file "scripts/duplicity" in lines 34-35 to look like this:
if os.path.exists(os.path.join(pwd, "../lib.linux-x86_64-2.7/duplicity")):
sys.path.insert(0, os.path.abspath(os.path.join(pwd, "../lib.linux-x86_64-2.7")))
May be you need to modify the paths according to your system's architecture and python version.
5. Now duplicity should be startable.
But now I have the problem, that a breakpoint I set is not respected. Duplicity just runs normally, but does neither break on exceptions nor on break points. What am I doing wrong now? Any ideas?
I learnt, what I did wrong. My breakpoints were not in the most current file, but in an old copy. I will never get the concept, why eclipse does not keep the files current, when they change on the hard disc. One has to update them to get it working. Most errorprone, but I finally fixed the problems debugging dup with pydev. All works fine now. The error - like most of the times - was between the ears in front of the monitor :)
Thx, for your time and patience.