[Python-de] Backuploesung aehnlich duplicity?

[Bernd Nawothnig]

On 2015-07-14, Marc Haber wrote:
>>> Und durch Pythons Eigenheit, in jeder minor-version subtil
>>> inkompatibel zu ihren Vorgängerversionen zu werden und damit die
>>> Distribution zu zwingen, Infrastruktur für die gleichzeitige
>>> Installation mehrerer Python-Versionen vorzuhalten, nochmal schlimmer.
>>
>> Das ist, wie so häufig, ein tradeoff. Du kannst natürlich alles und
>> jedes einfrieren, dann gibt es aber auch keinerlei Fortschritt mehr.
>
> Fortschritt will man im professionellen Serverbetrieb nur im Rahmen
> von sowieso geplanten Großmigrationen. 

Niemand hindert Dich, den Stand der Software auf einem beliebigen, von
Dir festzulegenden Stand einzufrieren. Allerdings ist das dann *Deine*
Entscheidung und *Du* musst dann ggf. Bugfixes selber nachpatchen. Das
kannst Du nicht von anderen Leuten erwarten.

> Was meinst Du, warum Red Hat den zehn Jahre lang supporteten RHEL
> schneller loswird als ein Bäcker frisch gebackene warme Semmeln?

Das ist mir bekannt. Was meinst Du, warum ich Ubuntu LTS verwende? Ist
nicht so extrem, aber geht schon auch in diese Richtung.

>> Aber schauen wir uns doch mal konkret an, wo etwa die
>> Abwärtsinkompatibilitäten zwischen Python2.5 und Python2.6 lagen:
>>
>> String Exceptions sind in Python2.6 nicht mehr erlaubt und es gibt ab
>> Python2.6 die Unterstützung von Kontext Managern, für die es das neue
>> Schlüsselwort with gibt. Natürlich darf es ab Python2.6 keine
>> Variablen mit der Bezeichnung with mehr geben.
>>
>> Nun gab es die Unterstützung von Kontext Managern aber bereits in
>> Python2.5 via __future__ *und* es ließ sich eine Warnung ausgeben,
>> wenn man Variablen 'with' genannt hat. D.h. Programme, die sich nicht
>> daran halten, sind ziemlich kaputt. Und daran hat Python nun wirklich
>> keine Schuld. Auch andere Programmierspracehn nehmen sich das Recht
>> heraus, bestimmte Sprachfeatures als deprecated zu markieren, um sie
>> dann später auch ganz zu entfernen.
>
> Und das Bytecodeformat ist gleich geblieben? 

Puh, ich meine in Python2 ist das schon lange dasselbe. Aber das
bringt Dir nichts, wenn Bibliotheken, die ja auch im Bytecode benötigt
werden, dann nicht vorhanden sind oder nicht passen.

Und in Python3 ist der Bytecode seit Version 3.3(?) versioniert und in
einem Unterverzeichnis namens __pycache__ abgelegt.

Was Du aber leicht patchen kannst, ist die Shebang-Zeile, in der ja
der Interpreter steht. Da schreibst Du dann eben statt (üblicherweise)

#v+
#!/usr/bin/env python
#v-

etwa:

#v+
#!/usr/bin/python2.5
#v-

rein. Und schon ist sichergestellt, dass dieses Executable unter
Python2.5 läuft, egal worauf /usr/bin/python nun zeigt.

> Ich frage das ernsthaft, weil ich natürlich als reiner Debianist nicht
> weiß, ob der Krampf mit dem für jede Python-Unterversion extra neu
> gebauten und im Paketnamen versionierten neuen Ökosystem nun an der
> Sprache oder an der seltsamen Paketierung liegt.

Das liegt schon an der Python Idee, für jede neue Unterversion eine
komplette Installation vorzusehen. Die Parallelinstallation mehrerer
solcher Unterversionen wird bereits von Python selbst unterstützt.

Aber was bitte schön ist daran schlecht? Das ist doch ein Vorzug von
Python, das bereits upstream vorzusehen. Du kannst ja auch unter Linux
Bibliotheken verschiedener Versionen parallel installieren.

Nebenbei macht PostgreSQL das ähnlich - aus denselben Gründen wie bei
Python, damit man sich nicht selber unnötig Fußangeln anlegt.

> Das ist mir auch völlig egal, denn für mich als reinen Debianisten ist
> das Ergebnis dasselbe: Sobald python draufsteht, tut's im
> professionellen Betrieb weh. "written in python" ist der sichere
> Auslöser für die Suche nach einer Alternative.

Was soll daran weh tun? Du frierst ein und fertig. Natürlich kannst Du
nicht erwarten, dass upstream ad ultimo Python2.5 unterstützen wird.
Das liegt dann selbstredend an dem, der diese Entscheidung so und
nicht anders getroffen hat, das ggf. nachzupatchen. Aber das gilt für
*jedes* Softwarepaket, nicht nur für Python.

Und alternativ installierst Du eben parallel noch Python*.*, je nach
Bedarf, wenn Dir die Patcherei zu aufwendig erscheint. Aber jetzt
laste das bitte nicht Python an, denn das ist dann *Deine*
Entscheidung, genau diesen Weg zu gehen. Python zwingt Dich nicht
dazu, im Gegenteil, es bietet Dir so lediglich kostengünstigere Wege
an.

Debian hat sich ja sogar den Luxus erlaubt, eine eigene
Firefox-Version zu forken und einzufrieren mit entsprechendem
Patchaufwand. Und erzähl mir bitte nicht, das sei nötig. Ubuntu zeigt
ja, dass es auch anders geht.




Bernd

-- 
no time toulouse