[gelöst] Mal schnell die neuste Python Version?

[buhtz]

Ich habe hier ein Debian 11/stable laufen und möchte es mir nicht zerschießen.

Wie bekomme ich den mal eben schnell die "neuste" Python Version (11 oder gerne auch 12) da drauf, um mal etwas zu testen, was evtl. ein Bug sein könnte?

[JTH]

Bin kein Freund davon, alles in Container zu verpacken – aber im Zweifelsfall könnt Docker mit dem Image python:3.11 ein Weg sein, mit passendem Aufruf natürlich.

Alternativ war Quellen runterladen, entpacken,

Code: Alles auswählen

./configure && make -j$(nproc)

und

Code: Alles auswählen

./python -m venv venv && . venv/bin/activate

gerade auch in 5 min erledigt und Python 3.11 in sauberer Umgebung einsatzbereit.

[reox]

Alternativ war Quellen runterladen, entpacken,

Es gibt auch pyenv um genau sowas automatisch zu machen: https://github.com/pyenv/pyenv
Ist aber nicht in Debian und braucht ein wenig Einrichtung

[buhtz]

Bin kein Freund davon, alles in Container zu verpacken – aber im Zweifelsfall könnt Docker mit dem Image python:3.11 ein Weg sein, mit passendem Aufruf natürlich.

Endlich mal ein realistischer Anwendungsfall für mich, damit ich mich mit Docker beschäftigen kann.
Zum Thema auch passend: https://realpython.com/python-versions-docker/

EDIT:
Vorsicht! Das war mein "erstes Mal". Es lief, aber kann sein, dass es auch elegantere Lösungen unter Debian gibt. Und Vorsicht: root/sudo!

• Ich musste nicht nur docker, sondern auch docker.io per apt installieren.
• Dann sudo docker run -it --rm python:3.11

Der Docker-Befehl hier lädt ein Docker-Image runter (woher auch immer und egal ob das "sicher" ist), startet es "interaktiv" (-it), so das man direkt in der Python-shell landet. Geht man da wieder raus wird der Docker container wieder "aufgeräumt" (--rm).

[tijuca]

Für den gewünschten Anwendungsfall würde es vermutlich schon reichen eine chrot Umgebung zu erstellen in der man sich das installiert was man benötigt. Wenn nicht mehr benötigt wirft man das chroot weg.

Ich benutzte hin und wieder ganz gerne distrobox als Tool zum Verwalten und benutzen von Docker oder Podman Containern, allerdings nur in Testing und Unstable paketiert. Ansonsten kann man dies aber recht ungefährlich als Benutzer im Home Verzeichnis installieren.

https://www.tecmint.com/distrobox-run-a ... tribution/

[shoening]

Hi,

wenn Du nur ab und zu mit Python etwas machst, dann würde ich auch zur „Container“ Variante greifen.

Alternativ zu docker.io könntest gäbe es unter Debian auch noch podman.

Wenn Du öfter mit unterschiedlichen Python Versionen herumexperimentierst, dann würde ich zu pyenv raten.

Viele Grüße
Stefan

[buhtz]

Wenn Du öfter mit unterschiedlichen Python Versionen herumexperimentierst, dann würde ich zu pyenv raten.

Dazu würde ich als Python-Entwickler nicht raten. Das Tool ist ein Hack, mehr nicht. Schon die Anleitung zur Einrichtung zeigt, wie sehr man hier am System rumbasteln muss.

Disclaimer: Vielleicht bin ich auch bei pyenv empfindlich, weil ich mal Zeit in ein Issue gesteckt habe, bis ich merkte, dass der Reporter pyenv nutzt und nicht versteht, wie es funktioniert.

[Michahe]

Das steht auch noch auf meiner ToDo-Liste:

Wenn Du öfter mit unterschiedlichen Python Versionen herumexperimentierst, dann würde ich zu pyenv raten.

Dazu würde ich als Python-Entwickler nicht raten.

Was ist den mit venv oder virtualenvwrapper?

[buhtz]

Was ist den mit venv oder virtualenvwrapper?

Ersteres ist IMHO der Python-Standard für virtuelle environments. Da geht es um die Pakete, nicht um die Interpreter. Oder kann man die auch festlegen?
Das zweite schau ich mir mal an.

[JTH]

Da geht es um die Pakete, nicht um die Interpreter. Oder kann man die auch festlegen?

Meines Wissens nicht beliebig, nein. Es geht dabei, wie du schreibst, primär um eine separate Umgebung im Bezug auf die installierten Pakete.

Die venv benutzt (durch Symlinks) zwar schon den Interpreter, den du zum Anlegen benutzt hast:

Code: Alles auswählen

python3.11 -m venv my_venv3.11
python3.10 -m venv my_venv3.10

Dazu musst du die konkret verwendete Version aber schon lokal greifbar haben.

[shoening]

Hi,

Dazu würde ich als Python-Entwickler nicht raten. Das Tool ist ein Hack, mehr nicht. Schon die Anleitung zur Einrichtung zeigt, wie sehr man hier am System rumbasteln muss.

Von meinem Verständnis ist die Anleitung zur Einrichtung ausreichend ausführlich und beschreibt auch gut, wie pyenv funktioniert.
Mit „Basteln“ hat das in meinen Augen weniger zu tun.

Disclaimer: Vielleicht bin ich auch bei pyenv empfindlich, weil ich mal Zeit in ein Issue gesteckt habe, bis ich merkte, dass der Reporter pyenv nutzt und nicht versteht, wie es funktioniert.

Das ist wahrscheinlich der menschlich nachvollziehbare Grund für die Abneigung - wenn man ein Problem untersucht und eine wichtige Information, die wesentlich zur Lösung beiträgt, einfach fehlt. Habe ich auch schon erlebt.

Ich habe mit pyenv bislang gute Erfahrungen gemacht. Als ich auf der Suche nach einem Build-System war, dass mit Python3 gut funktioniert, bin ich auf die Kombination mit tox und pyenv gestoßen. Das entsprach ganz gut dem, was ich an Build-System im Java Umfeld gewohnt war.

Viele Grüße
Stefan