ubuntuusers.de

noisefloor schrieb:

was mir dabei noch nicht klar ist: Python (2 und 3) ist in den main Quellen, die Pakete werden aus den Upstream Quellen gebaut, sprich aus dem Sourcecode der Python Foundation. Die beendeen aber den Support für Python 2, also gibt es ab dem 1.1.2020 keinen neuen Sourcecode mehr für Python 2. Will / wird Debian / Canonical dann ggf. selber Patches für Python 2 bereitstellen wenn nötig? Wäre ja sinnvoll, wenn man z.B. für Bionic Support bis 2023 gewähren möchte.

Pro-Linux schreibt:

Debian 10 wird Python 2 weiterhin bis zum Ende des Supports von »Buster« unterstützen. Bei Canonical gilt dies für die Lebenszeit von Ubuntu 18.04 »Bionic Beaver« LTS, also bis 2023. Beide Projekte wollen mit Debian 11 »Bullseye« respektive Ubuntu 20.04 LTS ihre Unterstützung von Python 2 einstellen.

*Hervorhebung durch mich

Hallo,

zwecks Aktualisierung in der Baustelle.

Gruß, noisefloor

Hallo,

fertig. Das Artikel ist aufgrund des Supportendes von Python 2 am 1.1.2020 umstrukturiert worden.

Gruß, noisefloor

Hallo zusammen,

noisefloor schrieb:

Hallo,

zwecks Aktualisierung in der Baustelle.

Gruß, noisefloor

Wie schön; allerdings halte ich die dortige Entfernung von Python 2 momentan für verfrüht, denn wenn auch dessen Support nun offiziell beendet ist, so sind jedoch im Python Package Index 🇬🇧 immer noch mit Python 2 programmierte Pakete/Module (siehe hierfür bitte diesen Post von mir) aufgeführt, z.B. Termsaver 🇬🇧 und Youtube-dlG 🇬🇧.

Solange dies so bleibt, würde ich zumindest Python 2 noch drinlassen.

Leider wird im Python Package Index 🇬🇧 nicht explizit darauf hingewiesen, dass man für mit Python 2 programmierte Pakete/Module den pip-Befehl gegenüber den mit Python 3 programmierten Paketen/Modulen modifizieren muss... ☹

Hallo,

Solange dies so bleibt, würde ich zumindest Python 2 noch drinlassen.

Das Pferd ist quasi tot und wir unterstützen das Reiten von toten Pferden nicht.

Wenn ein Maintainer eines Python Pakets es nicht geschafft hat, dass Projekt auf Python 3 zu portieren, dann machen wir das mal ganz sicher nicht zu "unserem" Problem im Wiki von ubuntuusers.de.

Wenn du der Meinung bist, du musst für dich privat noch Python 2 Progs / Software nutzen - dein Entscheidung. Deswegen wird das aber nicht in irgendeiner Form hier propagiert, dem nachzueifern.

Der Support von Python 2 durch die Python-Entwickler ist vorbei, das ist Realität. Und es ist ja nicht so, dass das in irgendeiner Weise schnell oder gar überraschend kam.

Gruß, noisefloor

Hallo noisefloor, Du schriebst u.a.:

(...)

Wenn du der Meinung bist, du musst für dich privat noch Python 2 Progs / Software nutzen - dein Entscheidung. Deswegen wird das aber nicht in irgendeiner Form hier propagiert, dem nachzueifern.

Der Support von Python 2 durch die Python-Entwickler ist vorbei, das ist Realität. Und es ist ja nicht so, dass das in irgendeiner Weise schnell oder gar überraschend kam.

Gruß, noisefloor

Gut, dann bitte ich hiermit um eine Klarstellung:
Was soll hier im Wiki mit den beschriebenen Python-2-Programmen passieren?

• Sollen diese aus den betreffenden Artikeln ganz entfernt werden?

  • oder nur, soweit sie sich lediglich per pip und/oder als Fremdpaket/PPA installieren lassen?

  • falls es (zusätzlich) ein Ubuntu-Paket gibt, das Programm aber drin lassen (bei Canonical gibt es Support bis 2023, siehe diesen Post) und lediglich die anderen Installationsarten entfernen?

Persönlich denke ich dabei v.a. an Termsaver 🇬🇧 und Youtube-dlG 🇬🇧.

Hallo,

ganz einfach: wo immer möglich die Python 3 Version präferieren. Und wenn es eine gibt die Python 2 Version nicht mehr erwähnen, weil Python 2 EOL ist.

Gruß, noisefloor

Hallo noisefloor,

das heißt also m.E. dann ja im Umkehrschluss, dass dort, wo es lediglich eine Python-2-Version gibt, die betreffenden Python-2-Programme weiterhin wie bisher im Wiki verbleiben dürfen und auch deren Installation via pip stehen bleiben darf, oder?

Hallo Hatte mich gewundert bis ich das fand. für python3 sind 2 Zeilen zum starten erforderlich. Eingetragen Gruß

Hallo,

@Win32netsky: was ist an dem Vorgehen den Python-spezifisch, im Sinne von, dass das für ein in Go oder Ruby oder Rust oder $FOO geschriebenes Programm anders wäre? Oder andersrum gefragt: warum hast du das nicht allgemeiner beschrieben im Artikel opt eingetragen?

Gruß, noisefloor