Ich arbeite mich gerade in Python + PyQt4 ein - funktioniert unter meinem Kubuntu echt super, macht auch richtig Spaß!
Da ich einige Anwendungen auch auf Arbeit nutzen möchte, ich aber auf unseren Windows-PC's nix installieren darf, würde ich gern ein portables Python auf dem USB-Stick nutzen.... nun das Problem... auf http://www.portablepython.com/ gibt es leider keine Version mit Qt4 und PyQt4...
Habt ihr eventuell irgendwo eine Portable-Python-Version mit Qt4 & PyQt4 gefunden, oder weiß jemand eventuell, wie man sich so einen Stick selber bauen kann?
Vielen Dank
krebsi83
Portable Python mit Qt4 / PyQt4
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
@ ms4py Danke für die Info.
Wenn ich das richtig verstehe, erstelle ich so einen Python-Stick mit den Modulen, welche unter dem aktuell installierten Python eingebunden sind. So also auch mit PyQt4.... wäre ja schon mal ein guter Schritt aber.... Muss dann nicht auch noch Qt4 auf dem Rechner installiert sein? Das brauche ich ja dann auch noch auf dem Stick (inkl. qtdesigner etc...)
Wenn ich das richtig verstehe, erstelle ich so einen Python-Stick mit den Modulen, welche unter dem aktuell installierten Python eingebunden sind. So also auch mit PyQt4.... wäre ja schon mal ein guter Schritt aber.... Muss dann nicht auch noch Qt4 auf dem Rechner installiert sein? Das brauche ich ja dann auch noch auf dem Stick (inkl. qtdesigner etc...)
Nein. Fürs Ausführen von Pythonscripten mit PyQt4-Importen brauchst Du nicht die Qt-Standardinstallation, sondern nur die Qt-DLLs und Skripte, die PyQt im Pythonpfad ablegt. PyQt4 hat noch ein paar weitere Abhängkeiten je nach genutzter Funktionalität - die, die über den Pythonpfad hinausgehen, sollten allerdings nur Windows-System-DLLs sein, die Python selbst schon benötigt (u.a. .NET).krebsi83 hat geschrieben: Muss dann nicht auch noch Qt4 auf dem Rechner installiert sein? Das brauche ich ja dann auch noch auf dem Stick (inkl. qtdesigner etc...)
Was anderes ist es, wenn Du PyQt selbst gegen Qt oder andere Bibliotheken gelinkt hast, dann sind deren DLLs auch nötig.
Die Executables sind ja alle im Python Verzeichnis, das funktioniert problemlos, eben getestet unter Win XP.
Batch-File muss natürlich etwas angepasst werden (befindet sich in diesem Fall direkt im Python-Verzeichnis):
Batch-File muss natürlich etwas angepasst werden (befindet sich in diesem Fall direkt im Python-Verzeichnis):
Code: Alles auswählen
@echo off
SET PATH=%CD%\Lib\site-packages\PyQt4\bin
SET PYTHONPATH=%CD%
python Lib\site-packages\PyQt4\examples\mainwindows\application\application.pyw„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
Doch, die Windows Binaries sind mit VS2008 kompiliert und benötigen deshalb auch das .Net Framework. Kann man aber auch in Form von DLLs mitliefern (s. auch Link oben).mkesper hat geschrieben:@jerch: "Normales" Python benötigt keinerlei .NET, das gilt nur für IronPython.
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
-
lunar
@ms4py: Bist Du sicher, dass das eine .NET-Assembly ist? Das ergäbe keinen Sinn, denn auch moderne Microsoft-Compiler übersetzen C noch immer in nativen Binärcode und nicht in CIL-Code. Dementsprechend sollte auch die C-Standardbibliothek von Microsoft eine normale, native DLL sein.
Gemeint ist hier die Abhängigkeit zur CRT. Mit Aufkommen von .NET hat sich Microsofts Linker-Modell geändert, nachzulesen hier: http://msdn.microsoft.com/library/abx4dbyh.aspx
Das ist keine eigentliche Abhängigkeit zu .NET, vielmehr bauen .NET und der klassische Weg auf diesen Unterbau auf. Ziel des ganzen ist es, die beiden Philosophien reibungslos zusammen führen zu können (vgl. gemischte Assemblies, verwaltet und nicht verwaltet, WinSxS usw.)
Das ist keine eigentliche Abhängigkeit zu .NET, vielmehr bauen .NET und der klassische Weg auf diesen Unterbau auf. Ziel des ganzen ist es, die beiden Philosophien reibungslos zusammen führen zu können (vgl. gemischte Assemblies, verwaltet und nicht verwaltet, WinSxS usw.)