Ist es schlimm, mein virtualenv-Verzeichnis innerhalb meines Git-Repositorys zu haben?

Question

Ich denke darüber nach, das virtualenv für eine Django-Web-App, die ich erstelle, innerhalb meines Git-Repositorys für die App zu platzieren. Es scheint eine einfache Möglichkeit zu sein, um Bereitstellungen einfach und unkompliziert zu halten. Gibt es einen Grund, warum ich das nicht tun sollte?

Answer 1

Ich verwende pip freeze, um die Pakete, die ich benötige, in eine requirements.txt Datei zu bekommen und füge diese meinem Repository hinzu. Ich habe versucht darüber nachzudenken, warum man das gesamte virtualenv speichern möchte, aber ich konnte keinen Grund dafür finden.

Answer 2

Das Speichern des virtualenv-Verzeichnisses innerhalb von Git ermöglicht es Ihnen, die gesamte App einfach durch ein Git-Clonen bereitzustellen (zusätzlich zur Installation und Konfiguration von Apache/mod_wsgi), wie Sie bemerkt haben. Ein potenziell signifikantes Problem bei diesem Ansatz ist, dass unter Linux der vollständige Pfad im Aktivierungs-, django-admin.py-, easy_install- und pip-Skript des venvs fest codiert wird. Dies bedeutet, dass Ihr virtualenv nicht vollständig funktionieren wird, wenn Sie einen anderen Pfad verwenden möchten, vielleicht um mehrere virtuelle Hosts auf demselben Server auszuführen. Ich denke, die Website könnte tatsächlich mit den falschen Pfaden in diesen Dateien funktionieren, aber Sie würden Probleme haben, wenn Sie das nächste Mal versuchen, Pip auszuführen.

Die bereits gegebene Lösung besteht darin, genügend Informationen in Git zu speichern, sodass Sie während des Deployments das virtualenv erstellen und die erforderlichen Pip-Installationen durchführen können. Normalerweise führen die Leute pip freeze aus, um die Liste zu erhalten, und speichern sie dann in einer Datei mit dem Namen requirements.txt. Sie kann mit pip install -r requirements.txt geladen werden. RyanBrady hat bereits gezeigt, wie Sie die Deploy-Anweisungen in einer einzigen Zeile aneinander reihen können:

# vor 15.1.0
virtualenv --no-site-packages --distribute .env &&\
    source .env/bin/activate &&\
    pip install -r requirements.txt

# nach der Veraltung einiger Argumente in 15.1.0
virtualenv .env && source .env/bin/activate && pip install -r requirements.txt

Persönlich lege ich diese einfach in ein Shell-Skript, das ich nach dem Git-Clonen oder Git-Pull ausführe.

Das Speichern des virtualenv-Verzeichnisses macht es auch etwas schwieriger, Pip-Upgrades zu handhaben, da Sie die aus dem Upgrade resultierenden Dateien manuell hinzufügen/entfernen und committen müssen. Mit einer requirements.txt-Datei ändern Sie einfach die entsprechenden Zeilen in requirements.txt und führen erneut pip install -r requirements.txt aus. Wie bereits erwähnt, reduziert dies auch das "Commit-Spamming".

Answer 3

Ich habe das Gleiche gemacht, bis ich begann, Bibliotheken zu verwenden, die je nach Umgebung unterschiedlich kompiliert sind, wie zum Beispiel PyCrypto. Mein PyCrypto-Mac würde auf Cygwin nicht funktionieren und auf Ubuntu nicht funktionieren.

Es wird zu einem absoluten Albtraum, das Repository zu verwalten.

Wie auch immer, ich fand es einfacher, das Pip Freeze & eine Anforderungsdatei zu verwalten, als alles in Git zu haben. Es ist auch sauberer, da man den Commit-Spam für Tausende von Dateien vermeiden kann, wenn diese Bibliotheken aktualisiert werden...

Answer 4

Ich denke, eines der Hauptprobleme, das auftritt, ist, dass das virtualenv möglicherweise von anderen Personen nicht verwendet werden kann. Der Grund ist, dass es immer absolute Pfade verwendet. Wenn Ihr virtualenv beispielsweise in /home/lyle/myenv/ war, wird es davon ausgehen, dass alle anderen Personen, die dieses Repository verwenden, den gleichen absoluten Pfad haben (es muss genau der gleiche absolute Pfad sein). Sie können nicht davon ausgehen, dass alle Personen die gleiche Verzeichnisstruktur wie Sie verwenden.

Es ist besser, wenn jeder seine eigene Umgebung einrichtet (mit oder ohne virtualenv) und dort Bibliotheken installiert. Das macht Ihren Code auch über verschiedene Plattformen hinweg besser nutzbar (Linux/Windows/Mac), auch weil virtualenv in jedem von ihnen unterschiedlich installiert ist.

Answer 5

Es ist keine gute Idee, irgendwelche umgebungsabhängigen Komponenten oder Einstellungen in Ihren Repositories einzuschließen, da einer der wichtigsten Aspekte der Verwendung eines Repositories vielleicht darin besteht, es mit anderen Entwicklern zu teilen. Hier ist, wie ich meine Entwicklungsumgebung auf einem Windows-PC (sagen wir, Win10) einrichten würde.

1. Öffnen Sie Pycharm und wählen Sie auf der ersten Seite aus, um das Projekt aus Ihrem Source-Control-System zu überprüfen (in meinem Fall verwende ich GitHub)

2. In Pycharm gehen Sie zu Einstellungen und wählen "Projektinterpreter" und wählen die Option, eine neue virtuelle Umgebung hinzuzufügen, Sie können sie "venv" nennen.

3. Wählen Sie den Basis-Python-Interpreter, der sich unter C:\Benutzer{user}\AppData\Lokale\Programme\Python\Python36 befindet (stellen Sie sicher, dass Sie die entsprechende Version von Python basierend auf Ihrer Installation auswählen)

4. Beachten Sie, dass Pycharm die neue virtuelle Umgebung erstellen und Python-Binärdateien und erforderliche Bibliotheken unter Ihrem venv-Ordner in Ihrem Projektordner kopieren wird.

5. Lassen Sie Pycharm seinen Scanvorgang abschließen, da es Ihr Projektskelett neu erstellen/aktualisieren muss.

6. schließen Sie den venv-Ordner von Ihren Git-Interaktionen aus (fügen Sie venv\ zur .gitignore-Datei in Ihrem Projektordner hinzu)

Bonus: Wenn Sie möchten, dass andere Personen (naja, fast einfach) alle Bibliotheken installieren, die Ihre Software benötigt, können Sie folgendes verwenden

pip freeze > requirements.txt

und geben Sie die Anleitung auf Ihrem Git an, damit die Personen den folgenden Befehl verwenden können, um alle erforderlichen Bibliotheken auf einmal herunterzuladen.

pip install -r requirements.txt