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 im Grunde genommen David Sickmillers Antwort mit etwas mehr Automatisierung. Ich erstelle eine (nicht ausführbare) Datei auf der obersten Ebene meines Projekts mit dem Namen activate und dem folgenden Inhalt:

[ -n "$BASH_SOURCE" ] \
    || { echo 1>&2 "Quelle (.) dies mit Bash."; exit 2; }
(
    cd "$(dirname "$BASH_SOURCE")"
    [ -d .build/virtualenv ] || {
        virtualenv .build/virtualenv
        . .build/virtualenv/bin/activate
        pip install -r requirements.txt
    }
)
. "$(dirname "$BASH_SOURCE")/.build/virtualenv/bin/activate"

(Wie in Davids Antwort angenommen wird, setzen Sie voraus, dass Sie ein pip freeze > requirements.txt durchführen, um Ihre Anforderungsliste auf dem neuesten Stand zu halten.)

Das obige gibt die allgemeine Idee wieder; das tatsächliche aktivieren Skript (Dokumentation), das ich normalerweise verwende, ist etwas ausgefeilter und bietet beispielsweise eine -q (leise) Option, verwendet python, wenn python3 nicht verfügbar ist, usw.

Dies kann dann aus jedem aktuellen Arbeitsverzeichnis geladen werden und wird ordnungsgemäß aktiviert, indem zuerst die virtuelle Umgebung eingerichtet wird, falls erforderlich. Mein Testskript auf oberster Ebene hat normalerweise Code in dieser Art, damit es ausgeführt werden kann, ohne dass der Entwickler zuerst aktiviert werden muss:

cd "$(dirname "$0")"
[[ $VIRTUAL_ENV = $(pwd -P) ]] || . ./activate

Das Laden von ./activate und nicht von activate ist hier wichtig, da letzteres jede andere activate in Ihrem Pfad finden wird, bevor es diejenige im aktuellen Verzeichnis findet.

Answer 2

Wenn Sie gerade die Entwicklungsumgebung einrichten, verwenden Sie die Datei pip freeze, da dies das Git-Repository sauber hält.

Dann, wenn Sie die Produktionsbereitstellung durchführen, überprüfen Sie den gesamten venv-Ordner ein. Dadurch wird Ihre Bereitstellung reproduzierbarer, Sie benötigen keine libxxx-dev-Pakete und vermeiden Probleme mit dem Internet.

Es gibt also zwei Repositories. Eins für Ihren Hauptquellecode, der eine requirements.txt enthält. Und ein Umgebungs-Repository, das den gesamten venv-Ordner enthält.

Answer 3

Ich denke, dass es am besten ist, die virtuelle Umgebung in einem Pfad innerhalb des Repository-Ordners zu installieren, vielleicht ist es sogar besser, ein Unterverzeichnis ausschließlich für die Umgebung zu verwenden (ich habe versehentlich mein gesamtes Projekt gelöscht, als ich eine virtuelle Umgebung im Stammverzeichnis des Repositorys erzwungen habe, zum Glück hatte ich das Projekt in seiner neuesten Version in Github gespeichert).

Entweder der automatische Installer oder die Dokumentation sollten den Virtualenv-Pfad als relativen Pfad angeben. Auf diese Weise treten keine Probleme auf, wenn das Projekt mit anderen Personen geteilt wird. Bei den Paketen sollten die verwendeten Pakete mit pip freeze -r requirements.txt gespeichert werden.