Kein Pip in virtuellen Umgebungen

[Justman10000]

Hi, ich habe mir Python selbst kompiliert und manbuell aufgespielt! Mit alles, sogar pip habe ich zum laufen gebracht... ODer... Nun ja... Fast alles:

Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Wenn ich mit virtualenv eine virtuelle Umgebung erstelle und dort pip verwenden will! Der Gag ist, dass dies nur bei virtuellen Umgebungen so ist, nicht jedoch außerhalb dieser, wo alles wie gewohnt funktioniert


Stats

Betriebssystem: Linux Debian 11
Python Version: Python 3.12.0a5
Pip Version: pip 23.0.1 from /usr/local/python/lib/python3.12/site-packages/pip (python 3.12)

[Axel-WAK]

Python 3.12 ist natürlich noch alpha und man hat da auch einige Module entfernt , distutils etc...

[Justman10000]

Python 3.12 ist natürlich noch alpha und man hat da auch einige Module entfernt , distutils etc...

Sind solche Module zwingend erforderlich? Weshalb sollte man solche Module entfernen? Wenn diese doch benötigt werden?

[sparrow]

Der Gag ist, dass man eigentlich keine Python-Version verwendet, die noch nicht final ist.
Und wenn man es tut, sollte man sehr genau wissen was man tut.
Warum brauchst du diese Version?

[__blackjack__]

@Justman10000: Das warum steht doch da in der Regel. Bei `distutils` wird auf PEP 632 verlinkt, wo ein ausführlicher Abschnitt „Motivation“ steht.

[narpfel]

@Justman10000: Funktioniert es, wenn die die venv mit `python -m venv` erstellst?

[Justman10000]

@Justman10000: Funktioniert es, wenn die die venv mit `python -m venv` erstellst?

Hatte ich schon vorher versucht:

Error: Command '['/home/certbot/bin/python', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

[Justman10000]

Vielleicht sollte man auch einfach nicht immer die Alpha nehmen

[snafu]

Gerade bei Versionen, wo sich sehr viel ändert, besteht immer die Gefahr, dass Python für sich gesehen zwar noch funktioniert, aber externe Module/Pakete nun Ärger machen. Das gab es mit dem Sprung auf 3.x und ich befürchte, dass die 3.12 auch noch so einige Probleme mit sich bringen wird. Einige Projekte, die nicht mehr aktiv betreut werden (damit meine ich *nicht* virtualenv), könnten einem durchaus um die Ohren fliegen.

[Justman10000]

Gerade bei Versionen, wo sich sehr viel ändert, besteht immer die Gefahr, dass Python für sich gesehen zwar noch funktioniert, aber externe Module/Pakete nun Ärger machen. Das gab es mit dem Sprung auf 3.x und ich befürchte, dass die 3.12 auch noch so einige Probleme mit sich bringen wird. Einige Projekte, die nicht mehr aktiv betreut werden (damit meine ich *nicht* virtualenv), könnten einem durchaus um die Ohren fliegen.

Frage ist halt, wie beschaffe ich diese Pakete jetzt?

[narpfel]

@Justman10000: Du hast bis jetzt die eigentlich wichtige Frage nicht beantwortet, warum du unbedingt eine Alpha-Version benutzen (und dann auch noch selbst kompilieren) möchtest.

[narpfel]

@Justman10000: Ich habe das gerade mal ausprobiert und bei mir funktioniert das hier ohne Probleme:

Code: Alles auswählen

apt build-dep python3.9
apt install git
git clone https://github.com/python/cpython.git
cd cpython
git checkout v3.12.0a5
./configure --prefix=/opt/python3.12.0a5
make -j
make install
cd /tmp
/opt/python3.12.0a5/bin/pip3 install virtualenv
/opt/python3.12.0a5/bin/python3 -m virtualenv venv
. ./venv/bin/activate
pip install ipython

Also kann ich dein Problem nicht nachvollziehen. Da müsstest du mal genauer beschreiben, was du gemacht hast.

Und du hast auch irgendwie mehrere Pythons installiert?

/home/certbot/bin/python

/usr/local/python/lib/python3.12/site-packages/pip (python 3.12)

[Justman10000]

@Justman10000: Ich habe das gerade mal ausprobiert und bei mir funktioniert das hier ohne Probleme:

Code: Alles auswählen

apt build-dep python3.9
apt install git
git clone https://github.com/python/cpython.git
cd cpython
git checkout v3.12.0a5
./configure --prefix=/opt/python3.12.0a5
make -j
make install
cd /tmp
/opt/python3.12.0a5/bin/pip3 install virtualenv
/opt/python3.12.0a5/bin/python3 -m virtualenv venv
. ./venv/bin/activate
pip install ipython

Also kann ich dein Problem nicht nachvollziehen. Da müsstest du mal genauer beschreiben, was du gemacht hast.

Und du hast auch irgendwie mehrere Pythons installiert?

/home/certbot/bin/python

/usr/local/python/lib/python3.12/site-packages/pip (python 3.12)

Wirklich seltsam, nachdem ich die Befehle in diesem Script folgte, funktioniert es! Habe das Script selbst zusammengebastelt

[Justman10000]

Obwohl, habe das Script mal auf einer anderen Maschine ausprobiert! Da ging es schon wieder nicht!

[sparrow]

Und du versuchst verzweifelt die nicht veröffentlichte Version zu benutzen, weil?

[Justman10000]

Und du versuchst verzweifelt die nicht veröffentlichte Version zu benutzen, weil?

Ich ein Typ bin, der gerne die Alpha verwendet, wenn er etwas selbst kompiliert... Zudem kapiere ich halt nicht... In dem Gitpod Workspace, wo ich das Script zuvor testete, funktionierte es ja ohne Probleme...

[narpfel]

@Justman10000: Tja, dann wirst du wohl auch der Typ sein müssen, der sich in die Anleitung reinliest und Schritt für Schritt rausfindet, wo seine Pythoninstallation kaputt geht. Ich sehe da spontan mindestens zwei Punkte in deinem Script, die möglicherweise und/oder ziemlich sicher früher oder später Probleme verursachen werden.

Mein Geheimtipp wäre an dieser Stelle, vielleicht mal die Fehlermeldung bei Google einzugeben? Und der zweite Geheimtipp ist, mehr Informationen zu liefern. Insbesondere die vollständigen Terminalbefehle zusammen mit ihren vollständigen Ausgaben. Damit muss man nicht unnötig im Nebel stochern, wenn man versuchen will zu helfen.

[__blackjack__]

@Justman10000: Anmerkungen zu den Installationsschritten: „underVersion“ ist eine etwas sehr wörtliche Übersetzung von „Unterversion“. Das wäre in English „subversion“.

Man verschiebt normalerweise keine Quelltexte in ein selbst angelegtes Unterverzeichnis in ``/usr/local/`` um dort dann Sachen zu kompilieren.

Und was man so wirklich gar nicht macht, ist dann das gleiche Unterverzeichnis dort als Ziel für das Installieren des kompilierten Ergebnisses anzugeben. Da können komische Effekte auftreten weil a) Dateien überschrieben werden könnten, und b) könnten Verzeichnisse dort genau so heissen wie die, in die installiert wird, womit dann Teile vom Endprodukt und Quelltext im gleichen Verzeichnis landen.

Es gibt ja Leute die sagen man sollte Quellen und Kompilat nicht im gleichen Verzeichnisbaum haben, aber Du hast da jetzt Quellen, Kompilat, *und* das installierte Programm im gleichen Verzeichnisbaum. Das ist Murks.

Zudem ist das auch kein Verzeichnisbaum in dem das System normalerweise Programme oder Bibliotheken sucht, oder der C-Compiler nach Include-Dateien. Dieses exotische Vorgehen ist ja auch der Grund warum Du bei einigen ``pip``-Aufrufen vorher CFLAGS setzen musst.

Mit den symbolischen Verknüpfungen wird das Python von der Linux-Distribution ersetzt, was leicht zu Problemen führen kann mit Programmen die auch über die Linux-Distribution installiert wurden, und das Systempython erwarten. Dafür gibt es das `altinstall`-Ziel im Makefile.

`get-pip.py` ist nicht mehr der aktuelle Weg. Seit Python 3.4 ist `ensurepip` Bestandteil der Standardbibliothek.

Die ``-r``-Option bei ``rm`` sieht ein bisschen „cargo cult“-Programmierung aus. Die Option macht bei Einzeldateien überhaupt gar keinen Sinn. Du scheinst die einfach *immer* zu verwenden, ohne darüber nachzudenken.

Zum deinstallieren löscht man nicht einfach so Verzeichnisse und Dateien. Da wird im Zweifel ja auch gar nicht alles erwischt das nach ``/usr/bin/`` verknüpft wurde, denn dort war ein ``*`` involviert — beim löschen gibst Du aber nur zwei explizite Dateinamen an. Hier auch wieder: Kein exotisches Installationsziel verwenden und manuell symbolische Verknüpfungen anlegen, sondern ``make uninstall``.