[OpenSlides users-de] Virtualenv und Paketbau

[Oskar Hahn]

Hallo zusammen,

nach dem gestern das Gespräch über Paketbau aufkam hatte ich
verschiedene Gespräche über die Handhabung von Abhängigkeiten. Momentan
verwenden wir virtualenv und installieren ganz genaue Versionen hinein.
Dieses Vorgehen würde ich gerne ändern und hätte hierzu gerne
Rückmeldungen von euch.

Mein Ziel ist es, für Endanwender von Virtualenv weg zu kommen.
Virtualenv ist für die Entwicklung eine wichtiges Tool, für Endanwender
jedoch nicht geeignet.

* Es macht die Installation schwerer (Schritte 1 und 2 in unserer
  Anleitung),
* es macht das Ausführen von OpenSlides schwerer (Schritt 5 in unserer
  Anleitung),
* es setzt die Verwendung des Terminals voraus, was abschrecken kann,
* es führt dazu das Programme im Home-Verzeichnis installiert werden
  müssen (Problematisch zB bei Backups),
* es führt dazu das Programme mehrfach installiert werden müssen.

Dagegen hat es natürlich den Vorteil, dass wir eine jungfräuliche
Umgebung haben, in der wir bestimmen können was genau installiert ist
und was nicht.

Meiner Meinung nach überwiegen die Nachteile.

Aus diesem Grund möchte ich gerne hin zu einer globalen Installation,
wobei es im Ergebnis egal ist, ob OpenSlides über ein
distributionsspezifisches Paket oder mit pip als Pythonpaket installiert
wird.

Für User die trotzdem eine Installation in ein Virtualenv möchten,
könnten wir die requirements_production.txt mit in das Paket legen. Es
könnte dann die jetzige Anleitung wie unter II verwendet werden mit dem
Zusatz, dass vor dem Befehl 'pip install OpenSlides-XX.tar.gz' noch der
Befehl 'pip install -r requirements_production.txt' ausgeführt werden
muss. Hierdurch wären alle Abhängigkeiten nach unserer Empfehlung erfüllt.

Wie wir das Ziel umsetzten OpenSlides ohne Virtualenv zu paketieren ist
für mich zweitrangig. Es muss jedoch berücksichtigt werden, dass der
Vorteil von Virtualenv nicht vorhanden ist und wir daher nicht
voraussetzten können, dass in einer globalen Umgebung eine bestimmte
Paketversion vorhanden ist. Auch können wir nicht erwarten, dass die
Umgebung nach der Installation von OpenSlides gleich bleibt. Weitere
Pakete könnten Installiert, vorhandene aktualisiert oder entfernt werden.

Mein Vorschlag wäre, dass wir für die Umstellung die älteste Version der
Abhängigkeiten reinschreiben, bei der wir wissen das es ununterbrochen
bis zu neusten Version funktioniert. Und zwar in der Form 'django>=1.5',
daher ohne bugfixrelease. Bei einem neuen Release lassen wir die
automatischen Tests zweimal durchlaufen. Einmal bei der minimalen
Version und einmal bei der maximalen Version. Letzte sollte der
requirements_production.txt entsprechen. Läuft die älteste Version nicht
passen wir entweder OpenSlides entsprechend an oder erhöhen die minimale
Version in der Abhängigkeit.

Dieses Vorgehen hat den Nachteil, dass OpenSlides in Umgebungen
ausgeführt werden kann, in denen nicht getestete Versionen der
Abhängigkeiten vorhanden sind. Entweder weil bei der Installation von
OpenSlides neuere Versionen der Abhängigkeit vorhanden sind oder weil
nachträglich andere Pakete aktualisiert werden. In diesen Fällen könnte
es passieren das OpenSlides nicht mehr läuft. Soweit OpenSlides nicht
mehr läuft müssen wir es fixen. Entweder in dem wir die den Code für die
neuere Version der Abhängigkeit anpassen oder indem wir die neuere
Version in der Abhängigkeitsliste sperren (zB: 'django>=1.5, <1.8').
Die alternative ist jedoch, dass OpenSlides auf jeden Fall nicht mehr
läuft, da die Abhängigkeiten nicht erfüllt sind.

Ich würde dieses Verfahren gerne ausprobieren. Jedenfalls ist es mir
wichtig von Virtualenv für Endanwender weg zu kommen.

Habt ihr andere Vorschläge für die Problematik?

Viele Grüße
Oskar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openslides.org/pipermail/users-de/attachments/20131118/c603f525/attachment.sig>