Marc Haber wrote:
[37/5247]mh@swivel:~/git/zg2dns $ grep -E 'class|import' get-root zg2dns/* get-root:from zg2dns.rootdata import DNSRootDataParser zg2dns/query.py:from rootdata import DNSRootDataParser zg2dns/query.py:class Zg2DNSQuery: zg2dns/rootdata.py:class DNSRootDataParser:
Versuche mal "zg2dns.query" zu importieren: | Traceback (most recent call last): | File "/tmp/t/test", line 3, in <module> | import zg2dns.query | File "/tmp/t/zg2dns/query.py", line 1, in <module> | from rootdata import DNSRootDataParser | ModuleNotFoundError: No module named 'rootdata'
Ich finde es wenig schön dass man abhängig vom Ort der Nutzung unterschiedliche Import-Statements schreiben muss, aber wenn das so ist kann ich damit leben. Ich hatte das Verhalten halt nicht für pythonisch gehalten.
Dein Fehler ist ein komplett anderer. Der Python-Interpreter fügt das Verzeichnis, in dem das aktuelle Script liegt, dem Suchpfad hinzu. Rufst du "get-root" auf, dann ist es ".". Damit findet "import zg2dns.rootdata" auch "zg2dns/rootdata.py". Rufst du aber "zg2dns/query.py" direkt auf, dann ist auf einmal das Verzeichnis "zg2dns" im Suchpfad. Also referenziert "import rootdata" auf einmal was anderes.
Wäre ich dnspython-Entwickler, hätte ich ja meine workingcopy von mir aus unter ~/git/dnspython ausgecheckt, und wenn ich irgendwas ausprobiere, würde das "import dns.query" in ~/git/dnspython/dns/resolver.py ja das dns/query.py aus dem Pythonpath anziehen und nicht das aus meiner Workingcopy, weil ich ja sicher auch die Releaseversion der Library installiert hätte.
Dafür gibt es "pip install -e ." z.B. Damit macht man das aktuelle Projekt im globalen Suchpfad des benutzten Interpreters verfügbar.
Wir arbeiten Modulentwicker in so einer Situation?
Module werden nicht als Scripte direkt aufgerufen, sind also auch nie ausführbar. Statt dessen werden sie mittels "python3 -m" aufgerufen. Im nächsten Schritt kommen dann Entry-Points, aus denen dann Scripte entstehen, welche in $prefix/bin landen. Bastian