Pyinstaller: Python-Apps für (fast) jedes Betriebssystem

Ich hielt es bisher für schwierig bis unmöglich, ein Python-Programm so zu bündeln, daß eine komplett selbstständige Applikationen dabei herauskommt, die sich selbst genügt und ohne weitere Abhängigkeiten (speziell ohne einen Python-Interpreter auf der Zielmaschine) startet. Doch dann fiel mir Pyinstaller in die Finger:

Pyinstaller baut aus Euren Python-Applikationen »Standalone Executables« unter Windows, Linux, macOS, FreeBSD, Solaris und AIX. Der Vorteil gegenüber ähnlichen Tools wie Py2app oder Py2exe ist einmal der, daß Python 2.7 wie auch Python > 3.4 unterstützt wird. Und dann wird das jeweilige Betriebssystem herangezogen um auch »Python-fremde« Bibliotheken, wie zum Beispiel SDL (wichtig für Pygame oder Pygame Zero) oder C-/FORTRAN-Bibliotheken wie zum Beispiel aus Numpy dynamisch mitzuladen.

Das bedingt natürlich, daß die Executables auf der jeweiligen Zielplattform mit Pyinstaller erstellt werden müssen, also eine macOS-Anwendung auf einem Mac, eine Windows-Anwendung auf einem Windows-Rechner und eine Linux-Anwendung auf einer Linux-Kiste. Wer also möglichst viele Zielplattformen bedienen will, muß sich einen großen Rechnerpark ins Arbeitszimmer stellen.

Ich habe daher – da ich keine anderen Rechner im Hause habe – Pyinstaller nur unter macOS Mojave testen können. Die Installation ist aber supereinfach, da Pyinstaller auf PyPI zu finden ist:

pip install pyinstaller

erledigt fast alles. (Bei mir schlug aber der erste Versuch fehl, da ich mein pip lange nicht mehr erneuert hatte und Pyinstaller nicht mit meiner veralteten Version spielen wollte, nach einem pip-Update lief aber alles wie geschmiert.)

Wenn man nun eine Applikation erzeugen will, navigiert man sein Terminal in das Verzeichnis, in dem die Python-Datei(en) liegen und kann dann zum Beipsiel mit

pyinstaller main.py

ein ausführbare Datei erzeugen. Im einfachsten Fall – wie oben – erhält man zwei Verzeichnisse (build und dist). In dist liegen alle Bibliotheken und das ausführbare Programm main, das man auf dem Mac mit einem Doppelklick starten kann.

Wer tatsächlich nur eine ausführbare Datei will, der ruft Pyinstaller mit der Option

pyinstaller main.py --onefile

auf. Dann liegt im Verzeichnis dist tatsächlich nur eine (fette) Datei main, die mit einem Doppelklick gestartet und an andere Nutzer verteilt werden kann. Den Rest (also build) kann man wegwerfen (getestet), er wird nur während des Build-Prozesses von Pyinstaller benötigt.

Hat man ein Fenster-Programm, also zum Beispiel eine Pygame-Anwendung, dann ist die Option

pyinstaller main.py --windowed

zu empfehlen. Dann findet man im Verzeichnis dist zusätzlich noch eine main.app, die genau so fett ist, wie der Rest des Ordners dist. Das ist ja auch kein Wunder, denn die main.app enthält noch einmal alle Dateien aus dist, sowie ein paar zusätzliche, die eine Macintosh-App benötigt.

Die gute Nachricht: Darum kann man außer der main.app alles andere wegwerfen, denn das fertige Programm benötigt den Rest des Verzeichnisses dist und das Verzeichnis build nicht mehr.

Die schlechte Nachricht: Diese eine Datei (entweder main oder main.app) kann sehr fett werden, da sie autonom sein will und alle benötigten Bibliotheken enthält. Ein einfaches »Hello World«-Beispiel kommt glatt auf knapp 6 MB, ein kleines Pygame-Spiel bringt 614 MB auf die Waage.

main.py ist übrigens keine verpflichtender Name, Ihr könnt die Programm-Datei nennen, wie Ihr wollt und alle Python-Dateien, die Ihr installiert, erkennt der Pyinstaller auch und bindet sie sauber ein.

Die Dokumentation kennt übrigens noch viel mehr Optionen, mit einem icon= könnt Ihr zum Beispiel auch ein eigenes Icon für Eure Applikation einbinden, per Default nimmt Pyinstaller nämlich sonst das eigene Logo.

Pyinstaller wird übrigens aktiv gepflegt, der jüngste Eintrag im Github-Repo ist (Stand 10. April 2019) gerade einmal zwei Tage alt.

Ich glaube, mit der Entdeckung von Pyinstaller habe ich das häufig nachgefragte Problem der Erstellung von Standalone-Applikationen aus Python (speziell Pygame) (für mich) entschärft. Sicher wird noch das eine oder andere Problem auftauchen, denn die Welt der Python-Module ist manchmal seltsam bis obskur, aber für die meisten Anwendungen sollte es ausreichen. Still digging!

---

1 (Email-) Kommentar

---

Das Problem ist be- und erkannt und leider uralt (außer, man programmiert in Maschinensprache und benutzt das Betriebssystem nicht, sondern BIOS-Aufrufe). Als ich letztes Jahr ein länger laufendes Software-Projekt begann, schaute ich mich auf dem Markt um, was es so an Software mit diesem Ziel gab. (In diesem Projekt werden ausführbare Dateien in einer „Cloud” verteilt, um dort verschiedene Routineaufgaben auszuführen. Aber jede Cloud hat ihr eigenes Python, ihr eigenes Perl, ihre eigenes ….) Zu diesem Zeitpunkt bot nur lua mit luastatic ein einigermaßen praktikables System an. Immerhin kommt man auf ein Hello World von einigen hundert KB mit musl, etwa 1.5 MB mit glibc (dabei ist der Interpreter für lua selbst etwa so groß), mein Projekt bringt gestrippt vielleicht 2,6 MB auf die Wage, weil es noch verschiedene Bibliotheken einbindet (und erlaubt, zur Laufzeit dynamisch nachzuladen — für meine Anwendung essentiall).
Insgesamt bin ich mit der Wahl von lua zufrieden, aber gerade dieser Aspekt ist jetzt in Python wahrscheinlich etwas besser gelöst worden. Insbesondere, dass luastatic schon längere Zeit nicht aktualisiert wurde, ist etwas unangenehm, wenn auch nicht sehr tragisch (bei lua tickt die Uhr doch etwas anders).

– Alexander A. (Kommentieren) (#)

---

(Kommentieren)