Bug 972474 - [abrt] eclipse-pydev-2.7.1-6.fc17: pydev_imports.py:26:<module>:ImportError: No module named queue
[abrt] eclipse-pydev-2.7.1-6.fc17: pydev_imports.py:26:<module>:ImportError: ...
Product: Fedora
Classification: Fedora
Component: eclipse-pydev (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Andrew Ferrazzutti
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-06-09 12:24 EDT by Andre Vehreschild
Modified: 2013-07-19 04:28 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-19 04:28:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
File: backtrace (6.79 KB, text/plain)
2013-06-09 12:24 EDT, Andre Vehreschild
no flags Details
File: core_backtrace (318 bytes, text/plain)
2013-06-09 12:25 EDT, Andre Vehreschild
no flags Details
File: environ (2.26 KB, text/plain)
2013-06-09 12:25 EDT, Andre Vehreschild
no flags Details
Picture of the python path settings. (58.09 KB, image/png)
2013-07-01 11:32 EDT, Andre Vehreschild
no flags Details
Configuration used for debugging to produce the crash. (103.38 KB, image/png)
2013-07-01 11:33 EDT, Andre Vehreschild
no flags Details

  None (edit)
Description Andre Vehreschild 2013-06-09 12:24:33 EDT
Version-Release number of selected component:

Additional info:
cmdline:        /usr/bin/python2.7 -u /usr/share/eclipse/dropins/pydev/eclipse/plugins/org.python.pydev_2.7.1.2012100913/pysrc/pydevd.py --vm_type python --client --port 54330 --file /usr/share/eclipse/dropins/pydev/eclipse/plugins/org.python.pydev_2.7.1.2012100913/pysrc/runfiles.py /home/vehre/rpmbuild/duplicity --port 51964 --verbosity 0
executable:     /usr/share/eclipse/dropins/pydev/eclipse/plugins/org.python.pydev_2.7.1.2012100913/pysrc/pydevd.py
kernel:         3.8.13-100.fc17.x86_64
runlevel:       unknown
uid:            1000
ureports_counter: 1
Comment 1 Andre Vehreschild 2013-06-09 12:24:49 EDT
Created attachment 758860 [details]
File: backtrace
Comment 2 Andre Vehreschild 2013-06-09 12:25:03 EDT
Created attachment 758862 [details]
File: core_backtrace
Comment 3 Andre Vehreschild 2013-06-09 12:25:27 EDT
Created attachment 758863 [details]
File: environ
Comment 4 Alexander Kurtakov 2013-06-25 09:25:49 EDT
Neil, please investigate whether this is reproducible with pydev master?
Comment 5 Andrew Ferrazzutti 2013-06-25 15:58:50 EDT
Andre, could you provide a reproducer please?
Comment 6 Andrew Ferrazzutti 2013-06-28 17:06:21 EDT
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.
Comment 7 Andre Vehreschild 2013-07-01 11:31:39 EDT
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_2.7.1.2012100913/pysrc/pydevd.py", line 3, in <module>
    import pydev_imports
  File "/usr/share/eclipse/dropins/pydev/eclipse/plugins/org.python.pydev_2.7.1.2012100913/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.
Comment 8 Andre Vehreschild 2013-07-01 11:32:37 EDT
Created attachment 767445 [details]
Picture of the python path settings.
Comment 9 Andre Vehreschild 2013-07-01 11:33:22 EDT
Created attachment 767446 [details]
Configuration used for debugging to produce the crash.
Comment 10 Andrew Ferrazzutti 2013-07-02 10:48:00 EDT
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.
Comment 11 Andre Vehreschild 2013-07-02 10:57:07 EDT
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.
Comment 12 Fedora End Of Life 2013-07-03 15:19:28 EDT
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.
Comment 13 Andrew Ferrazzutti 2013-07-10 10:17:36 EDT
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.
Comment 14 Andre Vehreschild 2013-07-10 13:56:58 EDT
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.
Comment 15 Andrew Ferrazzutti 2013-07-10 14:24:59 EDT
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.
Comment 16 Andre Vehreschild 2013-07-11 06:22:33 EDT
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.
Comment 17 Andre Vehreschild 2013-07-17 10:12:21 EDT
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?
Comment 18 Andre Vehreschild 2013-07-19 04:27:35 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.