Virtualenv: - verschiebbare Alternativen

Die umsetzbare Flagge war immer experimentell und hat nie wirklich funktioniert. Wir unterstützen es nicht mehr und die Funktion wurde vollständig eingestellt (daher die Hauptversion). Erläutern Sie Ihren Anwendungsfall, und wir können möglicherweise einen alternativen Ansatz vorschlagen.

CMD export branch && cd /build_dir && \
 apt-get update -y && apt-get upgrade -y && \
 pip3 install virtualenv && \
 virtualenv --always-copy --python=python3 env && \
 git clone http://user:pass@gitlab/dev/repo.git && \
 cd /build_dir/veil-repo/code/veil-common && \
 git checkout $branch && \
 python3 install.py -p /build_dir/veil-repo/code/cli-app/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/controller/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/node/ -v /build_dir/env && \
 cd /build_dir/ && \
 ./env/bin/pip3 install -r requirements.txt && \
 virtualenv --relocatable env

Dies ist ein Auszug aus Dockerfile. Funktioniert der Code korrekt, wenn ich das Flag --relocatable entferne? Das heißt, ich muss meine eigene isolierte Umgebung erstellen, die ich auf jede Weise kopieren kann.

In einem Docker würde ich sagen, 90% würde es. Aber um sicherzustellen, dass Sie mit demjenigen in Verbindung stehen müssen, der diesen Docker-Code verwaltet, kann es zu subtilen Unterschieden im Umgang mit Umsiedlungen kommen.

Wir haben diese Funktion manchmal verwendet, weil unser CI-System virtuelle Umgebungen in Verzeichnissen mit langen Namen erstellt hat. Der Name wäre lang genug, dass #! zu lang wäre und wir die Skripte in der Umgebung nicht ausführen können.

@ Nitori- In diesen Fällen wird empfohlen, das Format python -m zum Aufrufen der Tools im Allgemeinen zu verwenden 🤔

Das ist fair. Obwohl sich viele Python-Pakete schlecht verhalten und sich nicht so aufrufen lassen.

@ Nitori- Auch wenn dies der Fall ist, können Sie den Aufruf jederzeit erzwingen, indem Sie die ausführbaren Dateien über den Python-Interpreter im Binärordner aufrufen. z.B

{venv}/bin/python {venv}/bin/bad-bad-tool

wobei {venv} beliebig lang sein kann 👍

In meinem Unternehmen verwenden wir das Flag --relocatable in unseren Pipelines, um eine virtuelle Umgebung wiederzuverwenden und Zeit zu sparen. Wir verwenden GitLab, erstellen die virtuelle Umgebung in einem frühen Schritt, speichern sie als Artefakt und verwenden sie dann erneut, um eine auszuführen Reihe von parallelen Tests.

Wir wollten die Version von virtualenv anheften, aber aufgrund eines Fehlers haben wir die neueste Version abgerufen, sodass unsere Pipelines heute Morgen kaputt gegangen sind. Wir haben diesen Fehler behoben, sodass er angeheftet ist und jetzt alles läuft, und wir werden einen Weg finden, um die entfernte Flagge zu umgehen. Aber ich dachte, ich würde hier notieren, um meine Erfahrungen zu vermitteln, obwohl das Problem geschlossen ist und ich nicht erwarte, dass die Flagge in Zukunft unterstützt wird.

Da der neue App Data Seeder das Erstellen einer virtuellen Umgebung knapp 100 ms dauert, wird dieser Ansatz in Ihrem Anwendungsfall bevorzugt.

Wir verwenden --relocatable um einen Venv in einer Drehzahl zu bündeln. virtualenv wird in $ DESTDIR erstellt und schließlich in /opt/company verschoben.

Das ist mein Fall.

Würde es also helfen, das endgültige Ziel für generierte Pfade im Voraus zu übergeben?

@gaborbernat ja!

@gaborbernat noch muss die virtuelle Umgebung während der Erstellungsphase vor der Bereitstellung am endgültigen Standort verwendbar sein.

Ich bin mir nicht sicher, was hier eine gute Lösung ist. Ich bin offen für Vorschläge.

@gaborbernat In einem solchen Fall besteht das Standardverhalten darin, Builddir und Präfix zu unterscheiden.

virtualenv hat ein DEST_DIR Argument, das in diesem Fall irreführend sein kann. DEST_DIR ist der tatsächliche Venv-Speicherort, der effektiv ein Präfix ist (genau wie / usr, / usr / local usw.). Vielleicht sollte die Dokumentation von virtualenv LOCATION dies klarer machen.

Dann können Sie eine Option --destdir oder --root hinzufügen, die standardmäßig / . Auf diese Weise kann virtualenv isoliert in destdir (ähnlich wie bei einer Chroot). Ich weiß nicht, wie Python, Pip und andere Skripte damit umgehen müssen.

AFAIK das Problem ist, dass alle generierten Konsolenskripte den Pfad während der Erstellung für den Shebang fest codieren. Es gibt keine Standardmethode, mit der diese generierten Konsolenskripte mit Shebangs sowohl während des Builds als auch während des Laufs nach der Bereitstellung funktionieren. Es sei denn, nach dem Build repariert jemand die Shebangs. Aber das ist jetzt außerhalb des Bereichs für die Erstellung virtueller Umgebungen, also außerhalb unserer Kontrolle.

@gaborbernat meinst du, wir sollten dies in setuptools implementieren? Welcher Shebang kann sowohl isoliert zur Erstellungszeit als auch am Zielort zur Laufzeit verwendet werden?

Ich denke darüber nach, ein virtualenv-relocate -Skript zu schreiben, das Shebangs auf einer vorhandenen virtuellen Umgebung bearbeitet und sie an ihrem neuen Speicherort verwendbar macht. Etwas wie :

$ virtualenv-relocate /build/dir/venv /opt/company/app/venv
Rewriting shebang of bin/pip.
Rewriting shebang of bin/pip3.5.
...
$

Ich denke auch nicht, dass Setuptools ein guter Ort dafür sind. Diese Funktion sollte Teil des Build-Systems sein, das an Standort A erstellt und dann an Standort B bereitgestellt wird.

Nun, C-Projekt ermöglicht das isolierte Erstellen durch einfaches Bearbeiten von PATH und LD_LIBRARY_PATH. Egal welches Build-System Sie verwenden.

Ich bin nicht vertraut damit, wie C dies erreicht, vielleicht kann jemand erklären, darauf verlinken? Was vorher passiert ist, ist hier https://github.com/pypa/virtualenv/blob/legacy/virtualenv.py#L1880 -L1894; Wir haben im Grunde versucht, einige Pfade relativ zu machen: Skripte und pth / Ei-Dateien.

Mein Repository verwendet auch --relocatable und ich verwende ein Skript (nachdem die verschiebbare virtuelle Umgebung erstellt wurde), um zusätzliche Bibliotheken in die virtuelle Umgebung zu kopieren. Damit war es möglich, eine virtuelle Umgebung zu erstellen, die vollständig verschiebbar ist. Zum Beispiel verwenden wir dies unter Windows und fügen die virtuelle Umgebung unserem Installationsprogramm hinzu. Nach der Installation funktionieren die Python3-Programme einwandfrei mit der gepackten virtuellen Umgebung.

Der gleiche Anwendungsfall funktioniert auch auf Mac und Linux für uns ....

@ Gagi2k was Sie dort tun, zeigte bereits die Fragilität der aktuellen umsetzbaren Implementierung; Sie mussten einige zusätzliche Skripte ausführen, nachdem die Umgebung erstellt wurde, damit sie vollständig verschoben werden kann. Das Problem ist, wie Sie ein Paket vollständig verschiebbar machen können, hängt stark von Ihrer Zielumgebung ab. Die Idee hier ist also, dass virtualenv selbst aufgibt, seine Umgebungen vollständig verlagerbar zu machen (da dies in vielen Fällen nicht erfolgreich sein kann) ... und stattdessen den Job vollständig an Personen delegiert, die diese benutzerdefinierten Skripte schreiben, um dies zu erreichen. Skripte, die die Zielumgebung kennen, wissen also genau, was und wie viele Änderungen erforderlich sind, um etwas verschiebbar zu machen.

Richtig, fairer Punkt.

Mein Problem ist mehr oder weniger, dass ich jetzt die zuvor bereitgestellte Funktionalität neu erstellen und auf allen Plattformen + mehreren Distributionen testen muss, um genau das Gleiche wie die alte Funktion zu tun.

Ich denke, ich werde versuchen, vorerst bei einer älteren virtualenv-Version zu bleiben, bis ich oder jemand anderes die Zeit hat, dies zu implementieren.

@ Gagi2k siehe meinen Kommentar oben über eine virtualenv-relocate Projektidee. Ich werde gerne mit anderen zusammenarbeiten. https://github.com/spotify/dh-virtualenv/ kann ein guter Ausgangspunkt sein.

@bersace thx, ich habe jetzt schon den alten Code kopiert und daraus ein eigenständiges Python-Skript erstellt. Ich denke, ich werde das vorerst als Drop-In-Lösung verwenden, aber ich bin froh, in Zukunft zu etwas anderem zu wechseln oder die Skripte beizusteuern, die ich habe.

@ Gagi2k würde es dir etwas

@bersace Es ist noch in Arbeit: https://codereview.qt-project.org/c/qt/qtivi/+/290859

Das gesamte Update von virtualenv 20 verursacht weitaus mehr Probleme als erwartet. Die Wiederverwendung der alten Funktionalität, um die Skripte verschiebbar zu machen, ist keine große Sache, aber da sie jetzt auf venv basiert und mit dieser pyvenv.cfg viel komplizierter wird. ZB unter Windows hat die alte virtuelle Umgebung viele Basis-Py-Dateien kopiert/ lib / python(oder symlinked es). Jetzt werden sie überhaupt nicht mehr kopiert, aber der Pyvenv zeigt nur auf den ursprünglichen Ort. Sobald der ursprüngliche Speicherort aktualisiert wurde, muss Ihre virtuelle Umgebung damit umgehen und Sie müssen hoffen, dass alles Notwendige noch vorhanden ist. Das noch größere Problem ist https://bugs.python.org/issue39469 , was es schwierig macht, es an einen relativen Ort zu übergeben, an dem Sie alles einrichten, um die virtuelle Umgebung verschiebbar zu machen ...

Im Moment glaube ich nicht, dass es möglich ist (ohne dass pyvenv.cfg es unterstützt).

@gaborbernat Ich könnte virtualenv für das, was ursprünglich beabsichtigt ist, missbrauchen, aber wie

@ Gagi2k Ich bin sicher, ich vermisse hier etwas; Aber könnten Sie nicht einfach die pyenv.cfg hone als Teil der Installationsphase auf einem bestimmten Computer ändern?

@gaborbernat Ich könnte virtualenv für das, was ursprünglich beabsichtigt ist, missbrauchen, aber wie

Virtuelle Umgebungen wurden so konzipiert, dass sie immer auf einen Python-Interpreter auf einer Maschine verweisen. Die Grundannahme ist, dass Sie eine voll funktionsfähige Python-Umgebung auf dem Computer haben und nur mehrere separate site-packages dafür haben möchten. Ich kann einen gewissen Wert darin sehen, den Link nicht vollständig explizit zu machen (wie jetzt mit dem vollständig expliziten Pfad), aber wenn Sie diesen Pfad beschreiten, warum nicht einfach den ganzen Weg gehen und entweder PyInstaller oder pex verwenden, um Ihren Code mit zu verpacken die ausführbare Python-Datei im Voraus, ohne leicht zu brechende Referenzen?

@gaborbernat Sicher, das würde funktionieren, das größte Problem ist, dass die meisten Benutzer es gewohnt sind, den Ordner nach der Installation einfach umzubenennen, und er funktioniert weiter ...
Aber ich habe gerade herausgefunden, dass das Einstellen von PYTHONHOME auch den Trick macht, zumindest unter Windows habe ich es ohne Bezugnahme auf die ursprüngliche Installation zum Laufen gebracht.

pex sieht interessant aus und ich werde mir das genauer ansehen, danke für den Hinweis.

@gaborbernat noch, wie man ein virtualenv in einem builddir erstellt und es in einer .deb oder .rpm versendet?

@gaborbernat Sicher, das würde funktionieren, das größte Problem ist, dass die meisten Benutzer es gewohnt sind, den Ordner nach der Installation einfach umzubenennen, und er funktioniert weiter ...

Ich bin mir nicht sicher, warum sie das erwarten. Dies war nie der Fall; Selbst mit dem verschiebbaren Flag war dies in einer Teilmenge der möglichen Fälle der Fall. Daher wurde es mit v20 gestrichen.

@gaborbernat noch, wie man ein virtualenv in einem builddir erstellt und es in einer .deb oder .rpm versendet?

@bersace Dies hängt von vielen Ihrer Anwendungsfälle ab. Gewährleistet deb / rpm, dass Python am selben Speicherort auf dem Zielcomputer verfügbar ist? Wenn ja, reparieren Sie einfach die Shebang-Pfade während der Installation 👍

@gaborbernat reicht je nach

Das Ändern installierter Dateien auf postinst ist eine sehr schlechte Idee. Dies erfordert, dass alle Skripte aus dem dpkg-Bereich ausgeschlossen werden, damit dpkg sie beim Upgrade nicht berührt. Das ist nicht akzeptabel.

AFIAK, die beste Lösung wäre ein virtualenv-change-prefix , der alle Shebangs bearbeitet, um destdir zu entfernen, die vor der Archivierung des endgültigen Pakets ausgeführt werden sollen.

@bersace und auf was würdest du die Shebangs einstellen?

@gaborbernat der absolute Zielort. zB #!/opt/company/app/venv/bin/python .

Das würde jetzt bedeuten, dass die Bereitstellung dieses Pakets für eine andere neue Wurzel als / jetzt nicht unterstützt wird, nicht wahr?

@gaborbernat ja, von

Dies unterscheidet sich etwas von relocatable . Der Zweck besteht nicht darin, venv relativ zu machen, sondern builddir (debian / build / ... oder% builddir) und rundir (/) zu unterscheiden.

Schließen Sie dies, da es keinen umsetzbaren Gegenstand auf unserer Seite gibt. Ich würde empfehlen, die Diskussion hier oder über potenzielle Projekte fortzusetzen, die versuchen, dies zusätzlich zu virtualenv anzugehen.

Tatsächlich besteht eine Alternative darin, Abhängigkeiten von Anbietern zu ändern, ohne sie zu versionieren.

In meinem Fall muss ich ein Python-Paket mit den erforderlichen Abhängigkeiten komprimieren und es als 'Archiv' an Spark on Yarn übergeben, um die Ausführung meines Programms auf einem verteilten Spark-Cluster zu unterstützen. Obwohl dieser Vorgang von Anaconda abgeschlossen werden kann, kann die Unternehmenssoftware in meinem Unternehmen nicht verwendet werden. relocatable kann dieses Problem in der Vergangenheit lösen, aber jetzt ist es verschwunden.

In meinem Fall muss ich ein Python-Paket mit den erforderlichen Abhängigkeiten komprimieren und es als 'Archiv' an Spark on Yarn übergeben, um die Ausführung meines Programms auf einem verteilten Spark-Cluster zu unterstützen. Obwohl dieser Vorgang von Anaconda abgeschlossen werden kann, kann die Unternehmenssoftware in meinem Unternehmen nicht verwendet werden. relocatable kann dieses Problem in der Vergangenheit lösen, aber jetzt ist es verschwunden.

Hallo @jackhhh , haben Sie eine Problemumgehung für den vorhandenen Anwendungsfall gefunden?
Wir stoßen auf das gleiche Problem.