[OpenSlides users-de] Virtualenv und Paketbau

[Norman Jäckel]

Hallo an alle,

mir wäre wichtig, dass man das mit dem einfachen Befehl "pip install
openslides" vom PyPI gezogene Python Package in einer virtualenv so
installieren kann, dass es funktioniert und sich dies nicht nach
Verstreichen einiger Zeit quasi von selbst ändert, etwa wenn
Abhängigkeiten neuere, inkompatible Versionen herausbringen.

Ein ähnliches Problem hatten etwa die Leute von bleach, als ein neues
html5lib herauskam. Ihr Package war auf einmal kaputt, ohne dass sie
etwas dazu getan haben. Sie musste blitzartig neu releasen.

Denkbare Optionen:

* Mit der normalen setup.py wird ein Python Package angeboten, was nur
auf funktionierende, getestete Abhängigkeiten verweist, also kein
unbestimmtes "größer als" bei den Abhängigkeiten enthält.
* Weitere Setup-Dateien (wo auch immer sie liegen, z. B.
extras/setup-ubuntu-12.14.py) können existieren und von der Community
(wer es halt machen will) gepflegt werden. Diese übernehmen
mit Verweisen die Einträge aus der setup.py und modifizieren, was
mindestens nötig ist, um OpenSlides für die jeweilige Distribution zu
bekommen. Damit können dann die Paketierer arbeiten und ihre Pakete
erstellen.
* Von mir aus auch eine weitere extras/setup-global.py, mit der man ein
Python Package openslides-global.tar.gz erzeugen kann, dass sich sehr
tolerant verhält, damit man es mit pip auf einer beliebigen Maschine
global installieren kann. Dieses Python Package kann zusätzlich auf PyPI
bereit gestellt werden. Das strenge und das tolerante Paket müssen
deutlich voneinander unterscheidbar sein.

Ist es möglich, dass

$ source .virtualenv/bin/activate && pip install openslides

und

$ sudo pip install openslides

den Unterschied bemerkt und dann einmal dies, einmal ein anderes Paket
von PyPI zieht?

Viele Grüße
Norman

Am 18.11.2013 17:06, schrieb 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

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 901 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://mail.openslides.org/pipermail/users-de/attachments/20131118/230e7416/attachment.sig>