[gelöst] Wie am besten Python Scripts in einem File bundeln?

[framp]

Moin liebe Gemeinde,

ich bin dabei ein größeres bash Script von Scratch in Python neu zu schreiben. Dabei habe ich das Problem, dass ich meine gesammelten .py Files in einem zusammenpacken und verteilen will. Gefunden habe ich dieses Script. Dummerweise meldet es mit immer nur

Code: Alles auswählen

raceback (most recent call last):
  File "<string>", line 17, in <module>
ImportError: No module named main

Ich baue es mit

Code: Alles auswählen

zip collect.zip ../*.py; cat zipheader.sh collect.zip > collect.sh

und am Ende von collect.py steht

Code: Alles auswählen

if __name__ == "__main__":
    main()

Am Ende von zipheader steht

Code: Alles auswählen

del sys.argv[0:1]
import main
main.main()

so dass es eigentlich funktionieren sollte.

Weiss jemand was ich da falsch mache? Ansonsten bin ich auch anderen PackTools gegenüber aufgeschlossen. Hauptsache ist, dass meine gesammelten .py Werke in einem File resultieren welches aufgerufen werden kann

[Hyperion]

Ich halte dieses Vorgehen an sich für fragwürdig! Wieso implememtiert man nicht einfach ein Wrapper-Script, welches die anderen Scripte als Module importiert und deren Funktionalitäten nach außen hin kapselt? Alternativ baust Du Dir eben ein Paket und erstellst ein egg.

[framp]

Ich halte dieses Vorgehen an sich für fragwürdig!

Warum? Das WrapperScript sieht mir eigentlich sehr gut aus.

Code: Alles auswählen

Wieso implememtiert man nicht einfach ein Wrapper-Script, welches die anderen Scripte als Module importiert und deren Funktionalitäten nach außen hin kapselt?

Was meinst Du damit?

Alternativ baust Du Dir eben ein Paket und erstellst ein egg.

Ich will kein Python Script installieren. Ich will einfach die vielen Klassen in einem .py bundeln das die Leute aus der Community runterladen und dann ganz einfach ausführen können. Sind leider öfters LinuxBeginner dabei und denen will es es so einfach wie möglich machen das Script aufzurufen.

[BlackJack]

@framp: Das ist fragwürdig weil Python so nicht funtkioniert. Du versuchst da mit Gewalt die vorgesehenen Mechanismen von Python auszuhebeln um das in eine Datei zu zwingen.

Setz Dich lieber mit den dafür vorgesehenen Wegen Python-Programme zu "deployen" auseinander. Wenn es nicht systemweit installiert werden soll, reicht es aus alles in ein Archiv zu stecken. Auch Anfänger sollten in der Lage sein ein Archiv zu entpacken und eine darin enthaltene Datei zu starten. Wenn es aus der Verzeichnisstruktur nicht ersichtlich sein sollte welche Datei das ist, weil zum Beispiel im Hauptverzeichnis nur eine einzige ausführbare Python-Datei steht und alles andere sauber in einem eigenen Package verstaut ist, muss die nötige Information halt in der `README`-Datei stehen.

Ansonsten ist der übliche Weg eine `setup.py` und die `setuptools` wobei auch das Berücksichtigen von zum Beispiel `easy_install` keine schlechte Idee ist um es Anwendern einfach zu machen das Programm zu installieren.

[framp]

@framp: Das ist fragwürdig weil Python so nicht funtkioniert. Du versuchst da mit Gewalt die vorgesehenen Mechanismen von Python auszuhebeln um das in eine Datei zu zwingen.

Zugegebenermassen finde ich diese Methode auch etwas merkwürdig. Python hat so viele mächtige packages - und trotzdem finde ich keinen einfachen Weg mit Python einfach eine Menge von .py Dateien in einer Datei zu packagen. Da war ich froh über die o.g. Seite die ja eigentlich genau das macht was ich suche.

Setz Dich lieber mit den dafür vorgesehenen Wegen Python-Programme zu "deployen" auseinander. Wenn es nicht systemweit installiert werden soll, reicht es aus alles in ein Archiv zu stecken. Auch Anfänger sollten in der Lage sein ein Archiv zu entpacken und eine darin enthaltene Datei zu starten. Wenn es aus der Verzeichnisstruktur nicht ersichtlich sein sollte welche Datei das ist, weil zum Beispiel im Hauptverzeichnis nur eine einzige ausführbare Python-Datei steht und alles andere sauber in einem eigenen Package verstaut ist, muss die nötige Information halt in der `README`-Datei stehen.

Primäre Zielgruppe sind LinuxBeginners - und die haben schon genug Probleme aus der GUI mal ein shell Script aufzurufen. Bislang haben sie immer das shell Script runtergeladen und dann in der CommandLine aufgerufen. Das ist beschrieben wie man das macht - aber es gibt immer wieder Kandidaten die es trotzdem nicht auf Anhieb schaffen das Script auzurufen. Also will ich nicht noch weitere Komplexität wie das Auspacken von tars oder zips einbringen.

Ich könnte alle .py Files concatentieren und die import Lines löschen - und wäre auch schon fertig. Aber ich kann nicht glauben, dass es für dieses einfache - in meinen Augen häufiges Problem - eines Entwicklers in Python - keine einfache OutOfTheBox Lösung gibt ...

Ansonsten ist der übliche Weg eine `setup.py` und die `setuptools` wobei auch das Berücksichtigen von zum Beispiel `easy_install` keine schlechte Idee ist um es Anwendern einfach zu machen das Programm zu installieren.

Ich habe mir das mal diagonal angesehen - aber das ist Overkill für mein kleines Problemchen.

[BlackJack]

@framp: Einfach alles in eine Datei stecken und nur die ``import``-Zeilen löschen geht nicht. Jedenfalls nicht generell. Damit hebt man ja die Namensräume auf und jeder Name muss dann tatsächlich programmweit eindeutig sein. Und bei Modulen deren Inhalt man über den Modulnamen angesprochen hat, muss man auch noch weitere Änderungen am Quelltext vornehmen.

Eine Archivdatei entpacken gehört IMHO zu den Grundfähigkeiten die man haben muss, wenn man mit einem Rechner arbeitet. Das geht doch in der Regel auch ohne Kommandozeile, ist also auch für Mausschubser geeignet.

[framp]

@framp: Einfach alles in eine Datei stecken und nur die ``import``-Zeilen löschen geht nicht. Jedenfalls nicht generell. Damit hebt man ja die Namensräume auf und jeder Name muss dann tatsächlich programmweit eindeutig sein. Und bei Modulen deren Inhalt man über den Modulnamen angesprochen hat, muss man auch noch weitere Änderungen am Quelltext vornehmen.

Da alle Files ausser des Mains Klassen sind sehe ich da momentan kein Problem - wobei ich mit der Sichtbarkeit von Variablen in Python noch kämpfe. In Java ist das wesentlich systematischer definiert.

Eine Archivdatei entpacken gehört IMHO zu den Grundfähigkeiten die man haben muss, wenn man mit einem Rechner arbeitet. Das geht doch in der Regel auch ohne Kommandozeile, ist also auch für Mausschubser geeignet.

Ich könnte Dir jetzt diverse Links zu Forenbeiträgen geben, wo die Mausschubser zwar eine Datei runterladen konnten - aber es nicht auf Anhieb aufrufen konnten (x Flag muss gesetzt werden, er muss im richtigen Verzeichnis sein usw ...).

[BlackJack]

@framp: Du hast jetzt aber nicht eine Klasse pro Datei weil Du versuchst Java-Gewohnheiten auf Python zu übertragen!?

In Python ist das mit den Namensräumen auch "systematisch" gelöst, nur halt etwas anders als in Java. Es gibt Module in die man zusammengehörende Klassen und Funktionen gruppiert und Packages in denen man zusammengehörende Module gruppiert. Packages kann man selbst wieder in Packages stecken.

[Rebecca]

(x Flag muss gesetzt werden, er muss im richtigen Verzeichnis sein usw ...).

Das x-flag bleibt ja erhalten, wenn man ein tar-Archiv entpackt. Wenn es den Nutzern trotz vernuenftiger Anleitung nicht gelingt, ins richtige Verzeichnis zu wechseln, ist das imo nicht dein Problem. Irgendwelche Leute werden immer irgend etwas falsch machen, wenn sie dein Programm verwenden wollen; du kannst nicht fuer alle DAUs vorsorgen. ("Schatz, in der Bedienungsanleitung steht, dass man Haustiere nicht in der Mikrowelle trocknen soll." -- "Aber ich bitte dich, ein Elefant ist doch kein Haustier!" )

[cofi]

Da alle Files ausser des Mains Klassen sind sehe ich da momentan kein Problem - wobei ich mit der Sichtbarkeit von Variablen in Python noch kämpfe. In Java ist das wesentlich systematischer definiert.

Zusaetzlich zu dem was BlackJack gesagt hat: In Python gibt es die Konvention alles, was mit einem Unterstrich beginnt als Implementierungsdetail zu betrachten. Das ist ehrlich gesagt auch alles, was man braucht.

[framp]

...Du hast jetzt aber nicht eine Klasse pro Datei weil Du versuchst Java-Gewohnheiten auf Python zu übertragen!?

Nein, alle Klassen, die logisch zusammengehören (<=> Java package) stehen in einer Datei.

In Python ist das mit den Namensräumen auch "systematisch" gelöst, nur halt etwas anders als in Java. Es gibt Module in die man zusammengehörende Klassen und Funktionen gruppiert und Packages in denen man zusammengehörende Module gruppiert. Packages kann man selbst wieder in Packages stecken.

Kannst Du mir da eine URL empfehlen, wo das genauer beschrieben ist?

... Irgendwelche Leute werden immer irgend etwas falsch machen, wenn sie dein Programm verwenden wollen; du kannst nicht fuer alle DAUs vorsorgen...

Das ist sicherlich richtig - aber ich möchte diese Anzahl einfach möglichst gering halten

[BlackJack]

@framp: Hast Du schon das Tutorial in der Python-Dokumentation durchgearbeitet? Da werden auch Module und Packages erklärt.

[Hyperion]

Kannst Du mir da eine URL empfehlen, wo das genauer beschrieben ist?

Die Passage "Distributing Python Modules" in der offiziellen Doku z.B. Iirc steht auch im Tutorial einiges zu Modulen und Paketen.

Bist Du Dir eigentlich sicher, dass Du Klassen nicht als Modul "missbrauchst"? Du redest irgend wie nur von Klassen und nie von Funktionen... kommt mir bei einer großen Menge von Code ziemlich dubios vor.

[framp]

Danke für Eure Antworten. Sie sind zwar OT aber auch wichtig für mich. Jetzt heisst es für mich erst einmal lesen. Werde dann einen neuen Thread zum OT Thema erstellen und hier darauf verlinken.

[Hyperion]

Wieso OT? "Packaging" passt doch zum Threadtitel.

[framp]

Wieso OT? "Packaging" passt doch zum Threadtitel.

Jein - für mich nicht. Den Thread habe ich erstellt weil ich meine diversen .py Files in einem File bundeln möchte, so dass ein Benutzer nur noch ein File downloaden und es starten muss. Das OT Thema dreht sich für mich um Sichtbarkeit von Variablen/Methoden/Classes in Klassen/Modulen/Packages. Für mich sind das 2 Paar Stiefel - oder nicht?

[Hyperion]

Wieso OT? "Packaging" passt doch zum Threadtitel.

Jein - für mich nicht. Den Thread habe ich erstellt weil ich meine diversen .py Files in einem File bundeln möchte, so dass ein Benutzer nur noch ein File downloaden und es starten muss. Das OT Thema dreht sich für mich um Sichtbarkeit von Variablen/Methoden/Classes in Klassen/Modulen/Packages. Für mich sind das 2 Paar Stiefel - oder nicht?

Also Sichtbarkeit kann man natürlich in den Fokus einer solchen Diskussion stellen; ich hatte Dich zuletzt so verstanden, dass Du Dir für eben das "Bundeln" (wie Du es nennst) einmal die idiomatischen Python Werkzeuge angucken wolltest. Und das betrifft eben Module und Pakete

[framp]

Also Sichtbarkeit kann man natürlich in den Fokus einer solchen Diskussion stellen; ich hatte Dich zuletzt so verstanden, dass Du Dir für eben das "Bundeln" (wie Du es nennst) einmal die idiomatischen Python Werkzeuge angucken wolltest. Und das betrifft eben Module und Pakete

Ich muss zugeben dass ich momentan eine Menge Baustellen habe - deshalb vielleicht die Verwirrung. Vielleicht hilft Euch folgendes um mein Problem etwas zu verstehen:

Gegeben: Ein incrementell entwickeltes bash Script
Gesucht: Ein erweiterbares Script welches dieselben und mehr Funktionen und eine OOP Sprache benutzt
Kenntnisse: Java, C++, Smalltalk
Zielsprache: Python
Problem: Die Kenntnisse zu nutzen um das Gegebene in der Zielsprache zu implementieren. Python hat schon gewisse Unterschiede (zwangsläufig zu Java und C++, da interpretativ) die man kennenlernen muss

Vermutlich würde ich schneller zum Ziel kommen wenn ich alles in Java implementieren würde - aber ich will Python kennenlernen

[Leonidas]

Python hat schon gewisse Unterschiede (zwangsläufig zu Java und C++, da interpretativ)

Gerade da gibt es keinen Unterschied, da Python genauso wie Java zu Bytecode kompiliert wird und von einer VM ausgeführt wird. Und selbst bei C++ ist der Unterschied ob der Code nun kompiliert oder interpretiert wird eher nebensätzlich.

[snafu]

Python hat schon gewisse Unterschiede (zwangsläufig zu Java und C++, da interpretativ)

Gerade da gibt es keinen Unterschied, da Python genauso wie Java zu Bytecode kompiliert wird und von einer VM ausgeführt wird. Und selbst bei C++ ist der Unterschied ob der Code nun kompiliert oder interpretiert wird eher nebensätzlich.

Irgendwie glaube ich, dass er in Wirklichkeit den Unterschied zwischen einer dynamisch und einer statisch typisierten Sprache meinte.