Manche Python spezifische Anwendungen bei Leap sind doch etwas alt oder im Standard gar nicht enthalten. Auch scheitert teilweise ein eigener OBS Bau von bestimmten Python Anwendungen (in meinem Falle Gramps), wenn man nicht wirklich recht viele bestimmte Python Pakete oder gar Repos einbindet.
Wie seht Ihr das? Hattet Ihr damit auch schon Schwierigkeiten? Würdet Ihr Euch unter Leap ein aktuelles Python wünschen? Ist das für Euch Grund genug, zu Tumbleweed zu wechseln?
Ich kompiliere Python schon seit geraumer Zeit selber aus den offziellen Sources, installiere in ~/python-x.y.z, und benutze virtualenvs zum Umschalten zwischen den Versionen nach Bedarf, damit ich die mit dem OS vorinstallierte Python-Version auf keinen Fall anrühre und die Versionen säuberlich getrennt sind.
Ich habe mit dieser Methode gute Erfahrungen gemacht und betreibe meistens mehrere Python-Versionen parallel, weil ich in der Vergangenheit Software öfter mal an die jeweils aktuelle Python-Version anpassen musste, und dazu die ältere Version als lauffähige Referenz benötigte.
Ob so deine spezifischen Problem zu lösen sind, kann ich nicht sagen.
Äh, naja, gut und schön für Dich. Aber für mich als “einfachen” Nutzer empfinde ich das all zu viel des Guten. Ich kenne hier auch noch einen anderen Nutzer (ecsos), der sich verdammt viel selbst per OBS baut, um aktuelle oder aber überhaupt passende Pakete zu haben… Aber da fehlt mir außer der Motivation teilweise auch das nötige Verständnis. Ich würde mir wirklich wünschen, dass openSUSE mal ein aktuelles Python als Standard anbieten würde so wie viele andere Distributionen auch. Ich weiß um die Verzahnung mit und Kompatibilität zu SLE… Liegt das wirklich an SLE, dass Python bei openSUSE so alt/veraltet ist?!
Naja, grundsätzlich sind die Python-Installation(en), die der Anwender für seine Zwecke benötigt, und die, die die OS-Installation und deren Pakete für ihre Zwecke benötigen, nicht zwangsläufig das Gleiche. Flexibilität erfordert eben manchmal etwas Planung und Selbermachen.
Python selber Kompilieren, irgendwo unterhalb $HOME zu installieren und mit virtualenv zwischen den Versionen umzuschalten hat sich bei mir seit Jahren bewährt; virtualenv ist m.M.n. eine elegante Lösung des Versions-Installations-Problems, das es ja prinzipiell auch bei anderen Programmiersprachen geben kann. Das ist bei Python m.M.n. wirklich gut gelöst.
Abgesehen davon wäre so etwas ja auch eine Gelegenheit, seine eigenen Linux-Kenntnisse zu erweitern.
Bei mir sind beim Selber-Kompilieren verschiedener Python-Versionen selten Probleme aufgetreten, und wenn, fand ich eine Lösung, selber oder per Recherche.
OK. Gut für Dich. Aber nicht für mich. Das übersteigt sowohl meine Motivation als auch meine Kompetenz. (Und um die Kompetenz erst aufzubauen habe ich wiederum nicht unbedingt die Motivation). Ich möchte mein System benutzen (Anwendungen…), nicht einen vergleichsweise großen Zeitanteil administrieren. Bauen auf OBS ist ja noch ganz OK, aber lokales Bauen sehe ich wirklich nicht ein.
Was ich mal gemacht habe (und das war nicht schlimm, es musste halt nur gemacht werden), ist, dass ich mittlerweile TeXLive statt aus dem openSUSE Repo direkt vom Anbieter nutze (d.h. jedes Jahr ein neuer Install und Löschen des alten Zweiges, bei mir konkret aber nur alle paar Jahre und nicht jedes Jahr). (Und ja, ich nutze weit nach der Uni-Zeit als einer der wenigen in meinem Bekanntenkreis immer noch TeX, mittlerweile LuaLaTeX.)
Und auf OBS habe ich 7zip bauen lassen, um es in einer aktuellen Version verfügbar zu haben. Dazu war es notwendig, auch uasm bauen zu lassen (das musste extra hinzugefügt werden). Bei Tumbleweed ist das direkt dabei und damit baut auch 7zip ohne Probleme, aber bei Leap liegt uasm in einem extra OBS. Bei der Gelegenheit habe ich auch einen Branch von einem anderen home OBS mit dem Paket xfractint erstellt, so brauche ich lokal kein weiteres OBS Repo einzubinden.
Aber nein, lokal bauen werde ich nicht. Und mal ehrlich, ich habe von meiner Ausbildung einen gewissen Bezug zu Informatik und IT. Aber was ist mit Oma und Opa von nebenan oder der Germanistik-Studentin oder dem Kindergärtner von nebenan? Sollen solche Leute unbedingt Tumbleweed (mit seinen gewissen Besonderheiten…) nutzen, damit sie stets aktuell sind und alles verfügbar haben (manche Pakete sind bei Leap nicht einfach nur alt, sondern kaum bis gar nicht verfügbar (siehe 7zip)!)? Oder sollen die ernsthaft lokal bauen (wenn sie Leap benutzen)? Oder sollen sie sich damit abfinden? Oder einfach Microsoft Windows benutzen? Ich weiß natürlich, dass Open-Source-Software bzw. -Projekte i.A. und openSUSE i.B. (und die dort verfügbare Software) keine “Bring-Schuld” haben. Der Nutzer darf nicht “erwarten” im Sinne von “einfordern”, sondern halt “dankbar annehmen und eventuell selbst etwas beitragen”. Dass manche Leute vor Linux zurückschrecken, empfinde ich nun aber nicht als Wunder. (Windows wird i.d.R. direkt mit dem Rechner (subventioniert) mit ausgeliefert und ist startbereit. Seit 10 ist es i.A. immer aktuell. Programme gibt es dort als Binaries. D.h., installiert man das aktuelle Binary, hat man das aktuelle Programm. Klar, die Problematik mit Bibliotheken und Frameworks… (DLL-War…). Aber wenn man per Store, WinGet oder Chocolatey immer die aktuelle Binary bezieht, geht es ja einigermaßen. Außerdem muss man in der Linux Welt teilweise auch auf AppImage, Snap oder FlatPak zurückgreifen (jaja, OBS oder lokal bauen…) und hat dann ähnliche Probleme. (Die ePA-App meiner Krankenkasse ist proprietär und wird ausschließlich als Snap zur Verfügung gestellt. Also genau das Paket oder halt gar nichts. Von z.B. AnyDesk, was ich nicht nutze, gibt es zumindest ein Repo für RPM.)
Ich auch nicht. Aber aus welchem Grund sollte es möglich sein müssen, beliebig komplizierte Operationen mit einem OS durchzuführen, ohne sich ein Bisschen in Themen wie grundlegende Handgriffe mit Bash und ./configure --… && make && make install einzulesen?
Werkzeug, das für die Ansprüche von Experten und Profis gut geeignet ist, ist zumindest manchmal (wie oft, kann ich natürlich nicht beziffern) auch für Amateure, Hobbyisten etc. geeignet, setzt aber vielleicht etwas Mitarbeit der Letzteren voraus im Sinne von Einlernen und Übung.
