Closed GoogleCodeExporter closed 9 years ago
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
Issue 25 has been merged into this issue.
Original comment by helixblue
on 16 Nov 2009 at 12:32
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
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
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
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
Original issue reported on code.google.com by
ndbeck...@gmail.com
on 16 Nov 2009 at 11:50