pip install in virtual environment

[narpfel]

Achso. Die Pakete sind also eigentlich passend für die Pythonversion (die man gerade verwendet) schon vorcompiliert und nur wenn es sich um eine ältere, gerade genutzte Pythonversion handelt, werden sie entsprechend compiliert ?!

Genau. Oder wenn die Python-Version so neu ist, dass da noch niemand ein Wheel für gebaut hat.

Und wenn das so ist/wäre, wo/wie kann man feststellen, welche Versionen es vorcompiliert gibt, bzw. ob es Sourcen gibt, usw.?

Auf der PyPI-Seite vom Paket auf „Download files“ klicken, da werden alle für die aktuelle Version verfügbaren Builds gezeigt. Beispielsweise hier für wxPython und hier für PyQt6.

Source distributions sind das, was dann lokal auf dem eigenen Rechner kompiliert werden muss, wenn es nativen (C, C++, Rust, etc.) Code enthält. Wheels sind vorkompiliert.

Wie man sieht, hat wxPython für alle aktuellen Python-Versionen und für Windows (jeweils 32 und 64 Bit) und für macOS (ein Wheel, das sowohl x86_64 als auch AArch64 unterstützt) jeweils eigene Wheels (deswegen musstest du unter Linux selbst kompilieren); PyQt6 hat jeweils nur ein Wheel pro Betriebssystem, weil es `abi3` benutzt, wodurch native Python-Module mit mehreren CPython-Versionen kompatibel sind.

[mechanicalStore]

Wie man sieht, hat wxPython für alle aktuellen Python-Versionen und für Windows (jeweils 32 und 64 Bit) und für macOS (ein Wheel, das sowohl x86_64 als auch AArch64 unterstützt) jeweils eigene Wheels (deswegen musstest du unter Linux selbst kompilieren); PyQt6 hat jeweils nur ein Wheel pro Betriebssystem, weil es `abi3` benutzt, wodurch native Python-Module mit mehreren CPython-Versionen kompatibel sind.

Besten Dank für die Erklärungen. Was ich noch nicht ganz verstanden habe, ist das ABI-Tag. Zwar auf PEP 425 erklärt, aber irgendwie unverständlich. Steht z.B. für die Python Version 3.11.3 die letzte 3 für ABI3 ? Oder hat das damit gar nichts zu tun?

[narpfel]

Das hat gar nichts miteinander zu tun. Die erste Version von Python 3.11 war 3.11.0. Dann wurden ein paar Bugs gefixt und das dann als 3.11.1 veröffentlicht. Danach 3.11.2, ...

ABI3 ist ein Subset der C-API von CPython, von dem die Entwickler garantieren, dass es auch zwischen Minor-Versionen (also etwa von 3.10 auf 3.11) stabil bleibt. Hier die Doku dazu. Das sind aber eigentlich Details, mit denen man sich auf Python-Ebene (wenn man nicht gerade selbst in nativen Sprachen geschriebene Module als Wheels verteilen will) nicht auseinandersetzen muss. Da geht es um so Sachen wie „dieser Datentyp wird in C als struct mit dem und dem Feld dargestellt, wenn man da die Reihenfolge ändert oder neue Felder hinzufügt, bricht das die ABI-Kompatibilität“ oder „Ganzzahlen haben diese Anzahl an Bits und nicht eine andere“. Für alles außerhalb dieser „Limited API“ gilt diese Garantie nicht und man muss den Code für jede Minor-Version einzeln kompilieren.

[nezzcarth]

Achso. Die Pakete sind also eigentlich passend für die Pythonversion (die man gerade verwendet) schon vorcompiliert und nur wenn es sich um eine ältere, gerade genutzte Pythonversion handelt, werden sie entsprechend compiliert ?!

Neben der Python-Version, dem Betriebssystem und der Prozessorarchitektur gibt es insb. unter Linux auch noch den Sonderfall, dass einzelne Distributionen theoretisch abweichende C-Standardbibliotheken verwenden können. 99.8% aller gängiger Distros benutzen glibc und wenn es vorkompilierte Pakete für Linux gibt, dann eigentlich immer dafür. Aber es gibt ein paar nennenswerte Ausnahmen wie z.B. Alpine Linux , das musl verwendet und im Container/Docker-Umfeld eine gewisse Verbreitung hat. Auch in diesem Fall ist das Kompilieren von C-basierten Python-Bibliotheken aus den Quellen dann notwendig.

[mechanicalStore]

Danke für die Erklärungen. Auch wenn man sich nicht damit auseinandersetzen will/muss, ist das als Hintergrundwissen auf jeden Fall lehrreich.

Gruß