PYTHONPATH vs. sys.path

Question

Ein anderer Entwickler und ich sind anderer Meinung darüber, ob PYTHONPATH oder sys.path verwendet werden sollte, damit Python ein Python-Paket in einem Benutzerverzeichnis (z. B. Entwicklung) finden kann.

Wir haben ein Python-Projekt mit einer typischen Verzeichnisstruktur:

Project 
    setup.py 
    package 
     __init__.py 
     lib.py 
     script.py 

In script.py, müssen wir import package.lib tun. Wenn das Paket in Site-Paketen installiert ist, kann script.py package.lib finden.

Bei der Arbeit von einem Benutzerverzeichnis muss jedoch etwas anderes getan werden. Meine Lösung ist, meinen PYTHONPATH auf "~/Project" zu setzen. Ein anderer Entwickler möchte diese Codezeile am Anfang script.py setzen:

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))) 

Damit Python die lokale Kopie von package.lib finden.

Ich denke, das ist eine schlechte Idee, da diese Zeile nur für Entwickler oder Leute nützlich ist, die von einer lokalen Kopie laufen, aber ich kann keinen guten Grund geben, warum es eine schlechte Idee ist.

Sollten wir PYTOHNPATH, sys.path verwenden, oder ist beides in Ordnung?

Answer 1

Wenn der einzige Grund für die Änderung des Pfads für Entwickler ist, die von ihrem Arbeitsbaum aus arbeiten, sollten Sie ein Installationstool verwenden, um Ihre Umgebung für Sie einzurichten. Virtualenv ist sehr beliebt, und wenn Sie setuptools verwenden, können Sie setup.py develop einfach ausführen, um den Arbeitsbaum in Ihrer aktuellen Python-Installation zu installieren.

Answer 2

Ich denke, dass in diesem Fall mit PYTHONPATH eine bessere Sache ist, vor allem, weil es nicht (fragwürdigen) unnötigen Code einführt.

Nach allem, wenn Sie daran denken, Ihre Benutzer braucht nicht, dass sys.path Sache, weil Ihr Paket in Website-Pakete wurden installiert, da Sie ein Verpackungssystem wird verwendet.

Wenn der Benutzer wählt, von einer "lokalen Kopie" zu starten, wie Sie es nennen, dann habe ich festgestellt, dass die übliche Praxis ist, dass das Paket zu PYTHONPATH manuell hinzugefügt werden muss, wenn es außerhalb verwendet wird die Site-Pakete.

Answer 3

Ich hasse PYTHONPATH. Ich finde es spröde und nervtötend, pro Benutzer festzulegen (besonders für Daemon-Benutzer) und zu verfolgen, wie Projektordner sich bewegen. Ich würde lieber sys.path in den Aufrufskripten für eigenständige Projekte festlegen.

Jedoch sys.path.append ist nicht der Weg, es zu tun. Sie können leicht Duplikate erhalten, und es werden .pth Dateien nicht sortiert. Besser (und besser lesbar): site.addsitedir.

Und script.py wäre normalerweise nicht der geeignetere Ort, um es zu tun, da es innerhalb das Paket ist, das Sie auf dem Pfad verfügbar machen möchten. Bibliotheksmodule sollten sich nicht selbst berühren sys.path. Stattdessen haben Sie normalerweise ein hashbanged-Skript außerhalb des Pakets, das Sie verwenden, um die App zu instanziieren und auszuführen, und in diesem trivialen Wrapper-Skript würden Sie Bereitstellungsdetails wie sys.path -fobbing einfügen.

Answer 4

Zusammen mit den vielen anderen Gründen bereits erwähnt, können Sie auch outh zeigen, die hart codierte

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

spröde ist, weil es die Lage von script.py vermutet - es wird nur funktionieren, wenn Skript .py befindet sich in Projekt/Paket. Es wird unterbrochen, wenn sich ein Benutzer entschließt, script.py (fast) anderswo zu verschieben/kopieren/symlink.

Answer 5

Im Allgemeinen würde ich die Einrichtung einer Umgebungsvariablen (wie PYTHONPATH) eine schlechte Praxis sein. Während dies für ein einmaliges Debugging in Ordnung sein könnte, aber eine
regelmäßige Übung ist möglicherweise keine gute Idee.

Verwendung der Umgebungsvariablen führt zu Situationen wie "es funktioniert für mich", wenn jemand
sonst Probleme in der Codebasis meldet. Man könnte auch die gleiche Praxis mit der Testumgebung durchführen, was zu Situationen wie den Tests führt, die für einen bestimmten Entwickler gut laufen, aber wahrscheinlich fehlschlagen, wenn jemand die Tests startet.