Tox und Lib und Lib64 und Site-Pakete

Question

Ich verwende tox und coverage.py, um Tests meines Python-Projekts in meinem Continuous Build Server auszuführen. Ich habe auch ein Paket pkg_x von einem Hersteller (nicht verfügbar für PyPI), die ich installiert habe mit python3.5 setup.py install, die es in /usr/lib/python3.5/site-packages setzt. Jetzt muss ich das Paket für den Testcode verfügbar machen.

Mein aktueller tox.ini sieht wie folgt aus:

[tox] 
envlist = py35 

[testenv] 
deps = nose 
     coverage 
commands = coverage run -m nose [] 
sitepackages = True 

und ich die Tests wie folgt:

python3.5 -m tox -- --verbose --with-doctest 

Das spektakulär versagt - keiner der Abhängigkeits aufgeführten Pakete in meinem lokalen setup.py (zB öffentliche Sachen wie more_itertools) können gefunden werden, obwohl es Verzeichnisse wie .tox/py35/lib/python3.5/site-packages/more_itertools erzeugt, die die relevanten Pakete zu enthalten scheinen. Wenn ich .tox/py35/bin/python3.5 anwerfen, sieht sys.path wie folgt aus:

>>> [re.compile('.*\\.tox').sub('.tox', x) for x in sys.path] 
['', 
'.tox/py35/lib64/python35.zip', 
'.tox/py35/lib64/python3.5', 
'.tox/py35/lib64/python3.5/plat-linux', 
'.tox/py35/lib64/python3.5/lib-dynload', 
'/usr/lib64/python3.5', 
'/usr/lib/python3.5', 
'.tox/py35/lib/python3.5/site-packages'] 

Wenn ich die sitepackages = True Linie von meinem tox.ini entfernen, dann weiter ich komme, dass wie more_itertools Pakete und der Rest der Sachen in meinem setup.py Abhängigkeiten jetzt gefunden werden, aber das oben erwähnte Vendor-Paket pkg_x kann immer noch nicht gefunden werden. Und sys.path sieht wie folgt aus:

>>> [re.compile('.*\\.tox').sub('.tox', x) for x in sys.path] 
['', 
'.tox/py35/lib64/python35.zip', 
'.tox/py35/lib64/python3.5', 
'.tox/py35/lib64/python3.5/plat-linux', 
'.tox/py35/lib64/python3.5/lib-dynload', 
'/usr/lib64/python3.5', 
'/usr/lib/python3.5', 
'.tox/py35/lib/python3.5/site-packages', 
'/usr/lib64/python3.5/site-packages', 
'/usr/lib/python3.5/site-packages'] 

In keinem Fall hat .tox/py35/ scheinen den Hersteller Paket enthalten pkg_x überall. Und obwohl das Verzeichnis /usr/lib/python3.5/site-packages aufgeführt ist, wenn ich .tox/py35/bin/python3.5 manuell starte, wird pkg_x nicht wirklich gefunden, wenn die Tests ausgeführt werden.

Es sieht auch aus wie sitepackages = True hat den gegenteiligen Effekt von dem, was es bei http://tox.readthedocs.io/en/latest/config.html#confval-sitepackages=True|False dokumentiert ist, richtig tun?

Beratung sehr geschätzt!

Answer 1

Aus der Beschreibung, meine ich nicht zu nahe treten, aber vielleicht von Ihrem Verständnis, wie virtualenv und tox Arbeit muss zusammen arbeiten:

Tox eine virtualenv schafft, läuft dann aus es Tests, die Umgebung im Inneren.

Das Argument --sitepackages ist ein Schalter, der bestimmt, ob der virtualenv Zugriff auf global installierte Pakete erhält.

Der "normale" Weg, um tox zu laufen, wäre einfach zu sagen: tox; Installieren Sie es über Pip oder über ein OS-Paket sollte es in Ihren Weg. dh:

$ tox 

, die die gleiche ist wie zu sagen:

$ tox -c tox.ini 

Wo Sie tox direkt aufrufen, python -m tox, etwas damit anfangen kann, aber das ist eine rote Fahne für mich. Dieser Befehl scheint die relevante virtuelle Umgebung wahrscheinlich nicht zu aktivieren, was Ihre Probleme mit der Verfügbarkeit von Paketen erklären könnte.Es passt, denn wenn Sie sitepackages weglassen, fügt es tatsächlich die globalen Pakete hinzu, weil es denkt, dass es in einem virtualenv ist und fügt hinzu, was es denkt, sind die local Site-Pakete, obwohl sie tatsächlich global sind. Das Umgekehrte passiert, wenn Sie es wahr machen, denn wenn es nach globalen Paketen sucht, kann es sie nicht finden. Wie auch immer, weil du tox nicht wie erwartet anrufst, ist es genauso verwirrt wie wir.

Verwenden Sie also einfach den bereitgestellten Befehl.

Aber warten Sie, es gibt mehr: Sie sagen, Sie haben ein Paket, das erforderlich ist, aber nicht auf Pypi verfügbar. Also, wie wird Tox es installieren? Die Tox-Dokumente schlagen eine Reihe von Möglichkeiten vor (benutze eine requirements.txt), aber die direkteste Beschreibung hier ist, das env zu aktivieren und es manuell zu installieren.

Auch gut, wenn Sie weiter debuggen müssen: gehen Sie in das .tox Verzeichnis und aktivieren Sie das venv manuell. zB:

$ source .tox/testenv/bin/activate 

(wo testenv ist der Name, den Sie zwischen den Klammern in den tox.ini verwendet).

Installieren Sie das Paket aber Sie es getan haben, bevor zB: pip install pkg_x

die Venv deaktivieren, wenn Sie mit ihm auf diese Weise fertig sind:

$ deactivate 

Versuchen tox jetzt?

Wenn wir auf dem richtigen Weg sind learn more about virtualenv here

Answer 2

Es ist wie die Lösung für mein Problem aussieht, ist die commands Linie in meinem tox.ini aus, dies zu ändern:

commands = coverage run -m nose [] 

dazu:

commands = python -m coverage run -m nose [] 

Der Effekt ist, dass python ist jetzt ein virtualenv-map-Befehl, der das richtige Pyt lädt Hon Interpreter, lädt das Modul coverage und führt es aus. Ohne python -m, es findet nur was auch immer coverage ausführbare ist in meinem PATH und läuft es, mit unvorhersehbaren Ergebnissen. whitelist_externals könnte verwendet werden, aber es würde nur das Problem unterstützen.

Dann, wenn ich auch die sitepackages = True Zeilen hinzufügen, es sieht erfolgreich die pkg_x ich vom Hersteller installiert und meine Tests erfolgreich.