On 9/8/21 5:44 PM, Helmut Grohne wrote:
> As such, I err on dnspython being in need of a fix.
Dnspython isn't broken in any ways, it doesn't do any network access.
The only thing you're going to achieve is:
- more work for the maintainers (who will need to disable or patch the
tests).
- probably less tests (because the maintainer will probably choose to
simply disable the tests), which means less quality.
Again: what are you trying to achieve?
On 9/8/21 6:01 PM, Josh Triplett wrote:
> Now, that said, if the build process actually wants a DNS server to
> run tests against, it should provide or depend on such a DNS server,
> and configure it for such tests.
Just to be 100% sure we're on the same page: that's *not* what dnspython
is doing. It's a client library that's testing parsing of the
/etc/resolv.conf format, and it just expects it to be there for parsing.
The code has:
class Resolver:
def __init__(self, filename='/etc/resolv.conf', configure=True):
Later on, the class calls the method read_resolv_conf that has:
try:
f = stack.enter_context(open(f))
except OSError:
# /etc/resolv.conf doesn't exist, can't be read, etc.
raise NoResolverConfiguration
The test cases are of course instantiating the Resolver object to test
it, and calls it with the default configuration (ie: /etc/resolv.conf as
default), with something like this:
r = dns.resolver.Resolver(configure=False)
So, any test case that does that fails simply because the *FILE*
/etc/resolv.conf isn't there on the filesystem (and not because there's
no working DNS server, which would be just fine).
One could argue that the test cases should aways instantiate the
Resolver object with a non-default (test only) filename argument. Well,
I agree with that: please propose such a patch upstream. But does it
deserve anyone time? I don't think so. We're achieving absolutely
nothing doing this: this doesn't improve Debian...
Cheers,
Thomas Goirand (zigo)
