virtualenv vs. pipenv

[frankystone]

Sorry for writing in german. If you need english please mention it.

Hallo, ich denke ich kann auf deutsch schreiben da alle an der Webseite beteiligten Entwickler zur Zeit aus Deutschland kommen.

Nach dem großartigen Upgrade durch SirVer befinden sich neue Dateien im repo, u.a. Pipfile und Pipfile.lock. Nach etwas herumsuchen fand ich heraus das diese Dateien von pipenv kommen.

• pipenv ist die Weiter(?)entwicklung von virtualenv und soll es wohl irgendwann ersetzen
• Pipfile.lock und Pipfile sind die Ersetzung für pip_requirements.txt (so wie ich das verstanden habe)

Obwohl es möglich ist virtualenv und pipenv gleichzeitig zu verwenden, denke ich wir sollten uns auf ein Werkzeug beschränken um Fehler zu vermeiden. Z.B. dependabot nutzt wohl pipenv und verändert damit auch Pipfile.lock. Während ein manuelles Ausführen von pip freeze nichts an Pipfile.lock ändert. D.h. pip_requirements.txt und die generierten Dateien von pipenv enthalten u.U. verschiedene Versionen von Paketen. Das heißt wiederum: Nutzt jemand pipenv wird er andere Pakete installieren als jemand der virtualenv nutzt.

virtualenvironment erzeugt mit virtualenvund pipenv

Die virtualenvironments (wo Pakete installiert werden) werden je nach Werkzeug woanders erzeugt:

• ~/virtualenv wlwebsite: Hier entsteht das virtualenvironment direkt im Verzeichnis wlwebsite:

     ~/wlwebsite
         ├── bin
         ├── lib
  

• pipenv erstellt das virtualenvironment per default in ~/.local/share/virtualenvs/ des Benutzers. Das heißt jeder der auf dem Server mit der webseite arbeitet hat sein eigenes virtualenvironment. Diese Voreinstellung lässt sich umgehen wenn man die Umgebungsvariable WORKON_HOME definiert. Man kann also ein ähnliches Verhalten wie mit virtualenv erreichen. So sähe der komplette Befehlssatz für die Installation der Webseite mit pipenv aus:

  ~/mkdir wlwebsite
  cd wlwebsite
  export WORKON_HOME=$PWD
  mkdir code   # kann ausgelassen werden, imho
  git clone [email protected]:widelands/widelands-website.git widelands
  cd widelands
  pipenv install --dev     # Erstellt Virtuelle Umgebung und installiert Pakete in ~/wlwebsite/widelands-zufallswerte
  pipenv shell   # startet die virtuelle Umgebung
  # mache was mit webseite
  exit     # virtuelle Umgebung beenden
  

Der Nachteil ist das man die Umgebungsvariable u.U. immer wieder neu setzen muss, oder man trägt sie in die ~/.bash_profile ein. Wenn man vergisst die Umgebungsvariable zu setzen, wird bei Aufruf von pipenv shell ein neues Virtualenvironment in ~/.local/share/virtualenvs/ erstellt.

pipenv oder virtualenv

Wie oben erwähnt sollten wir nur eines dieser beiden Werkzeuge benutzen. Bisher sind wir mit virtualenv ganz gut gefahren. Ich bin mir nicht sicher welche Vorteile, außer einer genaueren Paketversionsverwaltung pipenv mit sich bringt. pipenv ist in der Benutzung auf dem server etwas komplizierter (Umgebungsvariable). Auch müssten alle systemd services umgeschrieben werden.

Meinungen?