You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You need an OSX machine with a default case insensitive filesystem (something you get if you install a recent version without any special partitioning options)
Install a recent python (I use python3 from brew) and virtualenv.
Install the default deps from python3.txt and tests.txt with pip install -r
Run py.test tests/unit/test_plugins/test_dns_eval.py
Actual result
==================================== ERRORS ====================================
__________ ERROR collecting tests/unit/test_plugins/test_dns_eval.py ___________
tests/unit/test_plugins/test_dns_eval.py:3: in <module>
import oa.dns_interface
oa/dns_interface.py:9: in <module>
import dns
../../.virtualenvs/oa-2.7/lib/python3.6/site-packages/dns/__init__.py:24: in <module>
from . import Opcode
E ImportError: cannot import name 'Opcode'
Expected result
Test success
Other notes
The reason for this is that py3dns and dnspython, being installed in modules dns and DNS respectively end up in the same directory because of the case insensitive nature of the OSX filesystem and end up clobbering each other.
Since dnspython seems like the more widely used and feature complete library I think that the non-hacky way forward here is to convince pyspf upstream to release a version that uses dnspython instead of py3dns and work around the problem. Fortunately it seems like the individual that uploaded the latest version of pyspf has some stale code in his github repo that makes pyspf dns library agnostic.
The text was updated successfully, but these errors were encountered:
Version information
head from github, 6740c10
Steps to replicate
pip install -r
py.test tests/unit/test_plugins/test_dns_eval.py
Actual result
Expected result
Test success
Other notes
The reason for this is that py3dns and dnspython, being installed in modules
dns
andDNS
respectively end up in the same directory because of the case insensitive nature of the OSX filesystem and end up clobbering each other.Since dnspython seems like the more widely used and feature complete library I think that the non-hacky way forward here is to convince pyspf upstream to release a version that uses dnspython instead of py3dns and work around the problem. Fortunately it seems like the individual that uploaded the latest version of pyspf has some stale code in his github repo that makes pyspf dns library agnostic.
The text was updated successfully, but these errors were encountered: