Skip to content
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

ImportError: No module named dns.rcode #24

Closed
GoogleCodeExporter opened this issue May 27, 2015 · 6 comments
Closed

ImportError: No module named dns.rcode #24

GoogleCodeExporter opened this issue May 27, 2015 · 6 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. installed namebench-0.9.3 (python setup.py build, sudo python setup.py
install)
2.
3.
 namebench.py 
Traceback (most recent call last):
  File "/usr/bin/namebench.py", line 41, in <module>
    from libnamebench import cli
  File "/usr/lib/python2.6/site-packages/libnamebench/cli.py", line 27, in
<module>
    import base_ui
  File "/usr/lib/python2.6/site-packages/libnamebench/base_ui.py", line
23, in <module>
    import benchmark
  File "/usr/lib/python2.6/site-packages/libnamebench/benchmark.py", line
33, in <module>
    import dns.rcode
ImportError: No module named dns.rcode

Looks like it was intstalled into subdir third_party:

...
byte-compiling /usr/lib/python2.6/site-packages/third_party/dns/rcode.py
to rcode.pyc
...


What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.


Original issue reported on code.google.com by ndbeck...@gmail.com on 16 Nov 2009 at 11:50

@GoogleCodeExporter
Copy link
Author

Thanks for the report. It looks like setup.py is a disaster at the moment, but 
an initial fix will be in the 
subversion tree shortly. My apologies for the breakage. 

For now, you can run namebench.py straight out of the source without running 
setup.py.


Original comment by helixblue on 16 Nov 2009 at 12:32

@GoogleCodeExporter
Copy link
Author

Issue 25 has been merged into this issue.

Original comment by helixblue on 16 Nov 2009 at 12:32

@GoogleCodeExporter
Copy link
Author

I don't think I like the idea of installing packages that I could get via other
means.  This could overwrite something that came from my standard linux
distribution, for example.  At least, make this optional.

Original comment by ndbeck...@gmail.com on 16 Nov 2009 at 12:46

@GoogleCodeExporter
Copy link
Author

Agreed, I'm not a big fan of the situation either. However, I have patched 
around it a bit in the trunk so that 
setup.py is usable. As mentioned before, there is no requirement to use 
setup.py however. If you do not want 
to install without the third_party package, you can set NO_THIRD_PARTY=1 in 
your environment before 
running setup.py, though you will likely need to clear your build directory 
first. 

At the moment, the third_party source tree does include one reliability patch 
for dnspython. See 
third_party/dns/README.namebench for the patch.

I would like to move installed third_party directory under libnamebench to 
avoid the possibility of collision, 
but I'm having some problems convincing setup.py to do so.




Original comment by helixblue on 16 Nov 2009 at 2:26

@GoogleCodeExporter
Copy link
Author

Installing third_party stuff into a subdir of libnamebench sounds like a good
solution.

Original comment by ndbeck...@gmail.com on 16 Nov 2009 at 2:33

@GoogleCodeExporter
Copy link
Author

I'm considering this one closed. I've opened a new bug for moving the 
third_party bits - issue 26

Original comment by helixblue on 16 Nov 2009 at 9:52

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant