py2exe und requests beißen sich?

[Sophus]

jerch: Wenn ich dich richtig verstehe, könnte py2exe ein Problem damit haben, dass er die reuests Bibliothek nicht erkennt, weil sie im try-Block ist?

[Sophus]

@snafu: Mit angeben? Du meinst in den include packen? Aber dann wird requests ja nicht mehr in die *.zip-Datei geladen, sondern so lose in den Ordner kopiert. Merkwürdig finde ich ja auch, dass in der*.zip-Datei, die von py2exe mit angelegt wird, ja unter anderem requests mit dabei ist.

[snafu]

jerch: Wenn ich dich richtig verstehe, könnte py2exe ein Problem damit haben, dass er die reuests Bibliothek nicht erkennt, weil sie im try-Block ist?

Um es präziser zu sagen: Der Gedanke war wohl, dass ein `ImportError`, auf dem nach jerchs Vermutung die Programmlogik von py2exe beruht (oder beruhen könnte), niemals bis zum py2exe-Code durchdringt, wenn er vorher von dir abgefangen wird. Immer vorausgesetzt, dass py2exe tatsächlich auf diesem Wege Module bzw fehlende Module erkennt.

[snafu]

@snafu: Mit angeben? Du meinst in den include packen? Aber dann wird requests ja nicht mehr in die *.zip-Datei geladen, sondern so lose in den Ordner kopiert. Merkwürdig finde ich ja auch, dass in der*.zip-Datei, die von py2exe mit angelegt wird, ja unter anderem requests mit dabei ist.

Gibt es bei py2exe etwa keine Funktion, um eine einzige ausführbare Datei zu erstellen? Soweit ich mich erinnere, gibt es sowas. Das ist zwar dann in Wirklichkeit ein sich selbst entpackendes Archiv, aber aus (naiver) Anwendersicht sieht es aus wie eine einzelne EXE-Datei.

[Daikoku]

@Sophus Sorry, mir ist ein wenig die Zeit ausgegangen, um mich etwas intensivere mit Deinem Problem zu beschäftigen.

Auf Grund meiner Erfahrung mit Windows, möchte ich definitiv ausschließen, das Du ein Problem mit dem Modul requests selber haben wirst.

Das sieht nach Windows 7, Python 2.7 und einer virtualenv Umgebung aus.

Anders dargestellt, so als wenn Du zwei verschiedene Python Laufzeitumgebungen installiert hast.
Die eine ist sauber und in der anderen fehlen einige Module.

Könntest Du bitte einmal posten:
- welche Windows Version Du benutzt,
- welche Python Version
. Python 2.7.xx ... [MSC v.1500 32 bit (Intel)] on win32 ???
. Python 2.7.xx ... [MSC v.1500 64 bit (AMD64)] on win32 ????
- welchen C-Compiler ?
- und ob Du Visual Studio als Entwicklungsumgebung benutzt ?

Kopf hoch, das Problem bekommen wir schon in den Griff.

Bis jetzt ist alles völlig normal, auch wenn die Pinguine sich jetzt bestätigt fühlen, das Windows als Entwicklungsumgebung eher suboptimal ist.
Aber 90% Windows, 8% MAC OS X und 2% Linux als Desktop-Betriebssystem sprechen da eine deutliche Sprache.

PS.: certs gehört zu site-packages/requests/certs.py. Alles was nicht funktioniert gehört zu requests.

[Sophus]

@Daikoku: Hier meine Angaben, soweit ich sie vervollständigen kann:

- Windows: Windows 7 Home Premium, 64bit, SP1 (Intel)
- Python: 2.7.6
- Kein Visual Studio installiert
C-Compiler? Ähm, da bin ich überfragt.

P.S. Windows läuft nicht als virtuelle Maschine, sondern Debain. Aber ich programmiere auf Windows. Debain nutze ich, um zu testen, ob mein Programm auch dort funktioniert.

Wenn es dir recht ist, kann ich dir gerne die EXE-Datei und die dazugehörigen Datei als Zip-Datei hochladen. Aber ich denke, das bringt auch nichts, hmhm?

[Daikoku]

@Sophus bitte keine EXE oder ZIP Datei. Das hilft jetzt nicht. vielleicht später. Danke für Dein vertrauen.

Also ich fasse einmal zusammen :
Du hast einen PC mit Windows 7 Home Premium, 64bit, SP1. Auf Windows eine virtuelle Maschine mit Linux, Debian.
Das ist soweit auch in Ordnung und auch völlig unkritisch, solange genügend Hauptspeicher min. 2 Gbyte zur Verfügung stehen.

Damit Du ein stabiles Windows bekommst, solltest Du auf automatische Windows Updates verzichten.
=> Start => Systemsteuerung => Windows Update => Einstellungen Ändern => nie nach Updates suchen (nicht empfohlen).
Ja, genau das tun was Microsoft nicht empfiehlt. Die Updates kannst Du jetzt nach Bedarf oder besser einmal im Monat manuell
durchführen. Das geht ganz einfach. => Start => Systemsteuerung => Windows Update => Nach Updates suchen.
Danach kannst Du installieren lassen, was Du wirklich brauchst.

Warum Python 2.7.6 und nicht 2.7.10 ?
Du entwickelst Doch ein komplett neues Programm, warum nicht Python 3.4 ?

Mir ist aufgefallen, das Deine Module nicht dem neusten Stand entsprechen.
So hat zum Beispiel QT, ich glaube mit Version 5.3, ein Änderung der WebEngine von webkit nach chromium sich vollzogen.
http://blog.qt.io/blog/2013/09/12/intro ... -webengine
Wenn Du jetzt eine Windows look and feel Applikation erstellst, wäre das schon wichtig.
Erlaube mir bitte zu fragen, warum Du mit einer steinalten QT Version arbeitest.

Du arbeitest nach dem Hypertext Transfer Protocol 1.1, aktuell ist aber 2.0 nach RFC 7540.
Ist momentan nicht ganz so wichtig, aber in 6 Monaten vielleicht schon.

Du siehst, das Du von Problem zu Problem laufen wirst.
Solange Du nur etwas für Dich alleine entwickelst ist das eigentlich egal, aber wenn Du etwas für Dich und Andere erstellst,
sollte das nicht nach einem softwaretechnischen Experiment aussehen, denn dann wirst Du ein surviving Kit benötigen.

Du brauchst doch irgendeine Entwicklungsumgebung auf Windows.
Wie erstellst Du Deinen Python-Code ??
Wie Debugs Du Deinen Python-Code ??

Du brauchst zwingend einen C-Compiler. Bitte jetzt nicht einfach etwas installieren, aber schau einmal:
https://www.microsoft.com/en-us/downloa ... x?id=44266

Darüber hinaus brauchst Du auch die Python for Windows Extensions.
https://pypi.python.org/pypi/pywin32
http://sourceforge.net/projects/pywin32/files

Schau bitte einmal
http://www.lfd.uci.edu/~gohlke/pythonlibs/
hier findest Du fast alle Python-Module als fertige Windows Binaries.

To install directly from a wheel archive:
https://pip.pypa.io/en/latest/user_guid ... rom-wheels

Ich möchte Dich jetzt nicht überfordern, installierst Du alles alleine oder hast Du eine helfende Hand ?
Ich möchte vermeiden Dir Dinge an die Hand zu geben, welche Deinen PC nachher nicht so gut bekommen.
Weil Gut gemeint ist nicht immer Gut gemacht.
Wenn Du zum Beispiel eine komplette C/C++ Entwicklungsumgebung installiert hast und ich Dir jetzt aus Unkenntnis dessen empfehle,
einen C/C++ Compiler für Python zu installieren könnte das zu Konflikte führen.

Ich glaube nicht, das py2exe und requests sich wirklich beißen sondern, welches das wirklich Problem darin besteht, das eine
nicht wirklich stabile Entwicklungsumgebung vorhanden ist.

Darüber hinaus hat die letzte Änderung von py2exe am 16.11.2008 stattgefunden. Microsoft hat einige Änderungen durchgeführt.
Mir ist nicht klar, wie das dann noch alles zu einander passen sollte.

Ich denke wir sollten einmal darüber nachdenken, eine stabile Entwicklungsumgebung aufzusetzen mit allen benötigten Module,
weil ansonsten ich befürchte, das wir uns von Fehler zu Fehler weiter durcharbeiten werden.

Sorry, aber das ist meine ehrliche Meinung, weil das alles, irgendwie so zusammen gebastelt aussieht.

[Sophus]

@Daikoku: Vielen dank für die ganzen Links.

Wie ich mit Python arbeite? Ich habe Python (x,y) installiert. Dazu PyCharm. In Python (x,y) sind so ziemlich viele Module/Bibliotheken dabei.

Zu deiner Frage, wieso ich mit Python 2.7.6 und QT4 arbeite. Nun, ich habe damit angefangen zu lernen, und in meinem Lernprozess hat sich so einiges an Quelltext angesammelt. Es ist schon ein kleines Mini-Projekt entstanden. Ich bin zum einen etwas ängstlich und zum anderen etwas "faul" mir sofort neue Sachen anzueignen. Das heißt die QT-Bindung müsste dann nochmal gründlich neu überarbeitet werden. Und zum anderen ist Python 3 noch nicht so ganz ausgereift, wie die 2.7-Version - auch was die Dokumentation anbelangt.

[Sirius3]

@Daikoku: solange man nicht wirklich Module entwickelt oder exotische Module braucht, braucht man für Python keinen C-Compiler. Die wichtigsten Module sind alle schon als compilierte Versionen vorhanden. Es ist also unnötig einen Programmieranfänger auch noch C aufzuhalsen. Kaum jemand hält seine Programme immer auf dem neusten Patch-Stand, ob jetzt Python 2.7.x oder 2.7.y ist völlig nebensächlich. Du glaubst gar nicht, wieviele 2.6 oder 2.5 Versionen noch produktiv eingesetzt werden. Und dann die Geschichte mit HTTP/2.0. Das RFC wurde erst vor 2 Monaten verabschiedet. Es gibt kaum einen Server der es unterstützt, geschweige denn ein Python-Modul. Also ersetze 6 Monate durch 6 Jahre, bevor das problematisch wird.

@Sophus: wenn Du den Fehler finden willst, solltest Du anfangen ein Minimalprogramm zu schreiben, dass den Fehler immer noch zeigt. Also alles rausschmeißen, was nicht relevant ist. Also ein Programm das requests nimmt um eine Datei herunterzuladen. Wenn Du das hast, kannst Du es ja hier posten.

[Daikoku]

@Sirius3 ich gehe mit Dir in vielen Dingen einig, aber hier habe ich eine konträre Meinung.

1. C-Compiler
Ich gebe Dir vollkommen recht, das die Bedienung eines C/C++ Compilers für einen Anfänger überfordernd ist.

1.1.
py2exe provide the Microsoft Visual C runtime DLL.
Du brauchst zwingend einen entsprechenden Microsoft C-Compiler installiert, weil Du ansonsten Dein Programm nicht an Andere weiter reichen darfst.
Natürlich kannst Du eine DLL aus Deinem Betriebssystem einfach weitergeben, nur dürfen darfst Du es eben nicht.
Erst wenn Du einen entsprechenden C-Compiler installiert hast, hast Du auch das Recht, die entsprechenden DLLs weiter zu reichen.
Nur so ist Dein Programm redistributable.
Bezogen auf diesen Thread gibt es drei mögliche DLLs, msvcm90.dll, msvcp90.dll und msvcr90.dll aber nur eine davon darfst Du weiterreichen.
In der Regel msvcr90.dll. Neben der DLL musst Du auch das Certifikat, VC90.CRT und das Manifest, VC90.CRT.manifest mit weiterreichen.
Wenn p2exe hier sauber arbeitet, sucht es nach einer entsprechenden Runtime und kopiert nicht nur die benötigte DLL, sondern auch das entsprechende Certifikat und das Manifest.

Here is what Microsoft has to say about distributing these dlls:
https://msdn.microsoft.com/en-us/librar ... s.90).aspx

Was jetzt noch zu 1.1. kommt, ist nicht ganz so wichtig, aber vielleicht gut zu wissen :
Soweit ich das auf die schnelle jetzt nachschauen konnte, ist das alles noch ein klein wenig komplizierter :
Python 2.4 und 2.5 benötigt das Microsoft Visual C++ 2005 Redistributable Package.
Python 2.6 und 2.7 benötigt das Microsoft Visual C++ 2008 Redistributable Package.

Microsoft Visual C++ 2008, SP 1 läuft ausschließlich mit Python 2.7.1 und ansonsten mit keiner anderen Python Version.
Weil es gerade passt, das ist jetzt einmal ein Beispiel, warum ich gegen automatische Updates bin.

Darüber hinaus sollten wir uns auch einmal ehrlich machen, das QT unter einer LGPL Lizenz gar nicht mit den Microsoft Lizenzbestimmungen
zu vereinbaren ist. D.h. ich kann nicht die LGPL Lizenzbestimmungen erfüllen und gleichzeitig die Microsoft Lizenzbestimmungen einhalten.

Es gibt zwei Wege LGPL konform unter Windows zu sein :
1.) alles was zu meiner Software gehört mit dem gcc zu übersetzen, was fast nicht möglich ist, oder
2.) der Kunde installiert alle Module selbst, wozu kaum ein Kunde in der Lage sein dürfte und schon gar nicht Willens.


1.2.
Zu einer entsprechenden Entwicklungsumgebung gehören für mich auch entsprechende Tools wie zum Beispiel
profilehooks - https://pypi.python.org/pypi/profilehooks.
Die Installation mit pip ist recht einfach. pip install profilehooks. Auch hier wird ein C/C++ Compiler benötigt.
Die Bedienung des C-Compilers erledigt pip. Ich selber muss da nichts weiter machen, nur installiert muss er eben sein.


2. HTTP/2.0
Es ist richtig, welches das RFC erst vor 2 Monate, 14.05.2015 verabschiedet wurde.
HTTP/2 ist jetzt nicht einfach so vom Himmel gefallen, sondern hat eine entsprechende Vorgeschichte,
welche auch erklärt, warum die Browser und Server das heute bereits unterstützen. Google => SPDY => HTTP/2.

Vorteile ? Bitte lesen : https://http2.akamai.com

Client Browser support :
- Chrome ab Version 41 supports HTTP/2 by default
- Chrome Canary ab Version 43 supports HTTP/2 by default
- Chrome for iOS ab Version 41 supports HTTP/2 by default
- Firefox ab Version 36 supports HTTP/2 by default
- Internet Explorer ab Version 11 supports HTTP/2 by default
- Microsoft Edge supports HTTP/2 by default
- Opera ab Version 28 supports HTTP/2 by default
- Safari ab Version 8.1 supports HTTP/2 by default

Ich denke wir haben mehr als 90% des Marktes.

HTTP/HTTPS Server :
- Apache 2.4.12 supports HTTP/2 via the module mod_h2
- IIS supports HTTP/2
- OpenLiteSpeed 1.3.11 and 1.4.8 support HTTP/2
- LiteSpeed Web Server 5.0 support HTTP/2
- Akamai Edge Servers support HTTP/2
- Jetty 9.3 supports HTTP/2

- nginx plans to support HTTP/2 by the end of 2015
- lighttpd has no support HTTP/2 planned in version 1.x

Ngix hat einen Marktanteil von ca. 14% der Rest ist zu vernachlässigen.
Somit unterstützen ca. 85% aller Server HTTP/2.

Welche Python Module von HTTP/2 jetzt profitieren würden oder könnten, kann ich nicht wirklich verifizieren,
weil ich mich bis jetzt, nicht im Detail, damit auseinander gesetzt habe.

Meine Motivation das überhaupt anzusprechen lag auch darin begründet, das wir hier vor ein paar Tagen in einem andrem Thread,
sehr ausführlich über APP-Entwicklungen für SmartPhones oder Tablets Stellung bezogen haben.
Egal für welchen Weg, native, HTML5+CSS+JavaScript oder eine hybrid Lösung man sich entscheidet, es ist ein relative einfacher Weg,
die Applikation auf HTTP/2 umzustellen. Meist reicht es aus, die Serverkonfiguration entsprechend anzupassen.
Für diejenigen, welche nicht native aufsetzen, ist es aus meiner Sicht schon wichtig, sich einmal mit HTTP/2 zu beschäftigen.


3. Kaum jemand hält seine Programme immer auf dem neusten Patch-Stand
Ich denke, wenn man weiss, was man da wirklich macht, kann man das durchaus so handhaben.
Ich bin das unter Windows so nicht gewohnt.
O.K vielleicht bin ich hier ein wenig zu pingelig, aber ich persönlich bin immer sehr gut damit gefahren.
(keine Release wechsel, sondern nur die Patches)

Um auf das Problem von Sophus zurück zu kommen. Ich habe einmal im Microsoft Developer Network nachgeschaut.
Und siehe da, das Problem ist bekannt. Nachdem ich jetzt wusst wo ich nach suchen musste, habe ich ähnliche Einträge auch hier
- http://stackoverflow.com/questions/2692 ... name-certs
- https://github.com/kennethreitz/requests/issues/2028
- http://stackoverflow.com/questions/2602 ... erts-error
gefunden.

Wobei https://github.com/kennethreitz/requests/issues/2028 für mich der beste Treffer war.

Das ist auch der Grund warum ich nach den einzelnen Softwareständen (Patches) gefragt hatte.

Wenn ich mir die Fehlermeldungen von Sophus anschaue, haben wir hier das gleiche Problem.
Alles funktioniert ausser requests. Sophus arbeitet mit der Version 2.6 aktuell ist 2.7.

Ich hätte jetzt als nächsten Schritt, ohne Sophus mit den ganzen Links da oben zu belasten, vorgeschlagen requests über pip
zu deinstallieren und anschließend wieder zu installieren. Vielleicht ist irgendeine Datei beschädigt.

py2exe braucht zwingend einen C-Compiler und auch pywin32, also installieren.
Beides gefährdet nicht die vorhandene Installation.

Sollte es danach immer noch nicht funktionieren, hätte ich den gleichen Weg beschritten, wie Du mit Deinem Minimalprogramm,
aber ich wüsste dann, auf welcher Basis ich aufsetze.

Zusammengefasst :
- Das Problem liegt ausschließlich an request.
- py2exe findet das Modul nicht.
- Fehlkonfiguration von py2exe oder möglicherweise ist eine Datei von dem Modul request beschädigt.

[sparrow]

Ich habe selten so viele Worte gelesen, die so wenige mit der Lösung des Problems zu tun haben. Wow.
Und du denkst wirklich, dass es sinnvoll ist Leuten zu sagen, sie sollen das automatische Update von Windows deaktivieren? Aber das wäre OT.

Wenn der Threadstarter irgendwann sagt was passiert wenn der requests in die includes aufnimmt und den ImportError nicht abfängt, dann können wir wieder zur Problemlösung übergehen. Beides kann er mit dem Minimalprogramm erschlagen, dass Sirius3 vorgeschlagen hat.

[Sophus]

Hallo Leute, auf Empfehlung von Sirius3 hin habe ich mir mal soeben ein kleines lauffähiges Programm geschrieben:

Code: Alles auswählen

#!/usr/bin/env python
#-*- coding:utf-8 -*-

FILE_NAME = "Test.py"

import requests
import sys

try:
    from PyQt4.QtCore import Qt
    from PyQt4.QtGui import QVBoxLayout, QPushButton, QDialog, QApplication, QPlainTextEdit

    print "STATUS [OK]  ", FILE_NAME, ": All modules are imported from PyQt4"
except ImportError:


    print "STATUS [FAILED]  ", FILE_NAME, ": All modules aren't imported from PyQt4"


def get_online_text():
    try:
        data = requests.get('http://xarphus.de/xarphus_version.txt')
        return data.text
    except Exception as ex:
        return ex
    
class MyTestDialog(QDialog):
 
    def __init__(self):
        super(MyCustomDialog, self).__init__()
        layout = QVBoxLayout(self)

        self.plain_text = QPlainTextEdit()
        layout.addWidget(self.plain_text)
        
        pushButtonText = QPushButton("Get Text", self)
        layout.addWidget(pushButtonText)
        pushButtonClose = QPushButton("Close Window", self)
        layout.addWidget(pushButtonClose)
 
        pushButtonText.clicked.connect(self.on_online)
        pushButtonClose.clicked.connect(self.close)


    def on_online(self):
        data = get_online_text()
        self.plain_text.setPlainText(data)

 
def main():
    app = QApplication(sys.argv)
    window = MyTestDialog()
    window.resize(300, 200)
    window.show()
    sys.exit(app.exec_())
 
if __name__ == "__main__":
    main()

Ich muss noch hinzufügen, dass ich mein requests von 2.6.0 auf 2.7.0 aktualisiert habe - in der Hoffnung, es könnte an der Version liegen. Fehlanzeige.

Hier die Console-Ausgabe - diesmal ist es ein anderer Fehler.



Ich habe beim Import die Ausnahmebehandlung entfernt.

@Daikoku: Das mit den DLL-Dateien ist mir bekannt. Dies habe ich ja in meiner py2exe-Setup.py-Datei berücksichtigt. Hier nochmal die Setup.py-Datei. in der Setup-Datei werden von Zeile 49-53 alle DLL-Dateien kopiert und sogar die Manifest-Datei. In Zeile 57 kopiere ich sogar die vcredist_x86.exe-Datei, damit der Anwender die Datei im Notfall selbst installieren kann. Und ich benutze Python 2.7.6, nicht mit 2.6.x

Mit dem Python-Interpreter läuft das problemlos, also ohne EXE-Datei von py2exe, sondern als Skript -Datei. Nur als EXE-Datei von py2exe gibt es Fehler. cx_freeze macht keinerlei Probleme. Die EXE-Datei von cx_freeze wird ordnungsgemäß ausgeführt und die Funktion ebenso.

Hier ist die Setup.py-Datei für Test.py. Dort sieht man in Zeile 24, dass requests zum includes hinzugefügt wurde.

[apollo13]

requests liefert manche libraries von selbst mit, erlaubt distributoren aber das unbundeln -- könnte sein, dass das die auto-detection von py2exe zerhaut. Schau ob du die explizit hinzufügen kannst…

[sparrow]

Das hier ist ein kleines Beispiel und funktioniert bei mir ohne Probleme:

setup.py:

Code: Alles auswählen

from distutils.core import setup
import py2exe
setup(console=['hello.py'])

hello.py

Code: Alles auswählen

import requests
r = requests.get("http://www.example.org")
print "Length:", len(r.text)

Code: Alles auswählen

>>> requests.__version__
'2.7.0'
>>> py2exe.__version__
'0.6.9'

Beides habe ich jeweils in ein virtualenv installiert. Python ist 2.7.9.
Schau doch mal ob das bei dir tut, und wenn es tut, dann baust du von da mal weiter, bis es nicht mehr geht.

Edit:
Da er das Modul 'email' nicht findet, und dieses in der exclude-Liste steht... könnte es da einen gewissen Zusammenhang geben? (das ist eine rhetorische Frage, weil das in diesem Fall der Fehler ist)

Die setup.py hat ja einen Umfang und ein Format, das eigentlich schon kaum noch zu warten ist. Und deshalb passieren genau solche Fehler.
Ich habe bisher nur 1x exe-Dateien ausgeliefert, damit die Benutzer das als "eine Datei, einfach benutzen" zur Verfügung hatten. Ich baue die mit pyinstaller. Der hat zwar auch seine Tücken, aber zumindest wirkt das Projekt lebendiger als py2exe.

Und lass das mit dieser Fehlerbehandlung von Importen. Du verschluckst den Fehler und gibst eine Warnung aus, die niemand liest. Bei deinem "kleinen" Beispielprogramm machst du das wieder bei den Importen von pyQt. Lass den Fehler auftreten. Dann crasht das Programm und schreibt sinnigerweise einen Stacktrace, der auch wirklich etwas aussagt.
Entweder du fängst einen Fehler ab (und dann kümmerst du dich auch darum, dass etwas getan wird), oder du kannst dir den try-Block sparen, weil das mehr kaputt macht als jemandem hilft.

Und... öhh... pyQt und PySide in einem Projekt?

[Sophus]

@sparrow: Du hattest Recht, es lag an das mail-Modul. Sobald ich dieses Modul aus der excludes entfernt habe, funktionierte die Exe-Datei auch wieder ordnungsgemäß. Danke. Zu deiner Aussage, dass meine Setup.py-Datei kaum zu warten sei. Inwiefern? Weil ich "zuviel" eingebaut habe? Bis jetzt habe ich mit meiner EXE-Datei keinerlei Probleme. Und zu deiner Frage, wieso PySide und PyQt in einem Projekt sind. Nun, die beiden unterscheiden sich kaum voneinander. Und da ich beides, also PyQt und PySide auf meinem Rechner habe, probiere ich erst beides, und füge dann zusammen. Ist es von Grund auf eine schlechte Idee?

[sparrow]

Zu deiner Aussage, dass meine Setup.py-Datei kaum zu warten sei. Inwiefern? Weil ich "zuviel" eingebaut habe? Bis jetzt habe ich mit meiner EXE-Datei keinerlei Probleme.

Klar hattest du ein Problem mit deiner exe-Datei. Der ganze Thread handelt davon.

Und zu deiner Frage, wieso PySide und PyQt in einem Projekt sind. Nun, die beiden unterscheiden sich kaum voneinander. Und da ich beides, also PyQt und PySide auf meinem Rechner habe, probiere ich erst beides, und füge dann zusammen. Ist es von Grund auf eine schlechte Idee?

Ja. PyQt und PySide sind beides Wrapper für Qt. Informiere dich, warum es beides gibt, was die Unterschiede sind und dann entscheide dich für eines von beiden. Man kann hinterher auch mit relativ wenigen Schmerzen wechseln, aber für die Entwicklung sollte man sich auf eins festlegen. Auf dem System kannst du beide haben. In einem Projekt will man nur eines von beiden verwenden.

[Sophus]

@sparrow: Ich meinte, mit meiner Setup-Datei hatte ich bisher keine Probleme. Damit meine ich, dass ich am Ende keinen Überblick habe, wo was nun steht und was gemacht wird. Das meinte ich. Daher verstand ich deine Aussage nicht, dass meine Setup-Datei kaum zu warten sei.

Zu dem beiden Rahmwerken - PySide und PyQt. Der größte Unterschied zwischen den beiden ist die Lizenz. Während PyQt davon ausgeht, dass man seine Programme kostenlos verteilt. Soll es kommerziell werden, dann muss man sich eine andere Lizenz kaufen. PySide dagigehend hat sowohl bei einem kostenlosen als auch bei einem kostenpflichtigen Vertrieb keinerlei Probleme. War das nicht der Grund, weshalb beide nebeneinander existieren. Und das sich PySide und PyQt kaum unterscheiden dachte ich deshalb, weil beide auf Qt ansetzen.

[cofi]

Genau das meinte sparrow: Du hattest ein Problem mit deiner setup.py, weil sie kaum wartbar ist. Warum? Du wunderst dich, dass `email` fehlt, obwohl du es explizit in der setup.py ausschliesst.

Zu Qt: Das ist nicht der Unterschied zwischen den beiden Anbindungen. GPL heisst nicht kostenlos und proprietaer heisst nicht kostenpflichtig. Man kann GPL Programme sehr wohl verkaufen.