standalone apps fuer windows mit python nicht moeglich

[KingNothing]

Ich behaupte das ist ein Windows-Problem. Unter Mac kann man alles schön in ein .app-Bundle packen, eine (ältere) Python-Installation ist schon an board, sonst kanns man es auch mit ins App-Bundle packen. Unter Linux/*BSD ist das Software-Management noch ausgefeilter, aber auch anspruchsvoller.

Ich würde dir empfehlen den Microsoft-Ansatz zu verfolgen, da alles andere meiner Meinung nicht zufriedenstellend ist:
Erstell doch einen Installer der das Skript mit einer (evtl abgespeckten) Installation ausliefert. Das wirkt zwar aus der sicht eines !Microsofters umständlich, funktioniert aber doch noch am besten.

[Py-Prog]

Microsoft hat ein Betriebssystem herausgebracht das kein Windows Nachfolger ist, es kennt keiner, und es ist (welch ein wunder) kostenlos. Soviel ich davon verstanden habe sollen darauf keine *.exe laufen aber Laufzeitumgebungen, weil sich Skripte leichter 'überwachen lasen'. Könnte eine 'Lösung' des Problems sein, es hat einige voreile gegenüber Windows aber trotzdem will es keiner haben, des halb ist Singularty kostenlos, mal schauen was die mit Windows 8 machen.

Oh, wenn es noch interessiert: Microsoft hat es mit dem ziel entwickelt ein sehr sicheres Betriebssystem heraus zubringen.

[BlackJack]

@Py-Prog: Singularity ist nicht kostenlos weil es keiner haben will, sondern weil es ein Forschungsprojekt ist und auch nur für akademische, nichtkommerzielle Nutzung kein Geld kostet.

Ob das praktisch so einsetzbar ist, steht auf einem anderen Blatt.

[lunar]

@Py-Prog: Singularity ist ein Forschungsprojekt, und praktisch nicht einsetzbar. Kostenlos ist es im Übrigen auch nur für die akademische Nutzung. Es „will keiner haben“, weil keiner Betriebssysteme nutzen möchte, die praktisch nicht funktionieren.

[funkheld]

Der grösste Mist ist, das es ab Python 3... fast keine Erweiterungen gibt, die man in 2.6 gebraucht hat für bestimmte Zwecke. Immer wieder wird der Kack gesagt: das machen wir bald....ho..ho...

Da wurde mit Python 3..., ein neuer Scheiss geschaffen...,neuer Anfang...so ein Mist.... :K

[BlackJack]

@funkheld: Du musst Python 3 ja nicht benutzen wenn Dir die 2er im Moment noch besser gefällt.

Deine Fäkalsprache ist übrigens nicht so toll.

[Py-Prog]

Löschen ging nicht mehr.

[HerrHagen]

Und was hat das alles mit dem ursprünglichen Thema zu tun...?

[burli]

Wieso gibt es eigentlich keine reine Laufzeitumgebung von Python für Windows? Das msi Paket ist doch soweit ich weiß ein All In One.

Und wie wäre es, wenn man einen Installer verwendet, der überprüft ob Python installiert ist und die nötigen Installer runterläd und ausführt. Es ist ja mit Python alleine nicht unbedingt getan wenn man z.B auch noch PyQt oder GTK verwendet.

Mal ehrlich, unter Windows muss man für etliche Programme Java oder .Net installieren. Da kommts auf Python doch nicht mehr drauf an, vor allem bei den Festplattengrößen, die man heute hinterher geschmissen bekommt.

[pudeldestodes]

Gibt es eigentlich einen technischen Grund dafür, dass Python unter Windows standardmäßig im Wurzelverzeichnis installiert wird? Falls nicht wäre es doch wirklich sinnvoll das unter Program Files/Python/Python x.y abzulegen.

Ansonsten finde ich es unhandlich, dass der Installer mir nicht zumindest optional die Möglichkeit gibt den $PATH automatisch anpassen zu lassen. Und schlussendlich wäre es für viele Anfänger sicherlich hilfreich, wenn man Pythonprogramme nicht unbedingt aus der Konsole starten muss, wenn man Fehlermeldungen sehen möchte. Ein eigener Menüeintrag dafür im "Rechtsklickmenü" bei Klick auf eine .py-Datei wäre von daher recht hübsch.

[Xynon1]

Gibt es eigentlich einen technischen Grund dafür, dass Python unter Windows standardmäßig im Wurzelverzeichnis installiert wird?

Nicht das ich wüsste, den kannst du doch aber bei der Installation ändern.

Und schlussendlich wäre es für viele Anfänger sicherlich hilfreich, wenn man Pythonprogramme nicht unbedingt aus der Konsole starten muss, wenn man Fehlermeldungen sehen möchte.

Dafür wird ja unter Windows mit voller Absicht IDLE im .msi-Paket mitgeliefert.

[syntor]

@pudeldestodes: Vermutlich UAC.
Was Fehlermeldungen betrifft: Logfiles.

Microsoft hat ein Betriebssystem herausgebracht das kein Windows Nachfolger ist, es kennt keiner, und es ist (welch ein wunder) kostenlos. Soviel ich davon verstanden habe sollen darauf keine *.exe laufen aber Laufzeitumgebungen, weil sich Skripte leichter 'überwachen lasen'.

Da hast du doch die Erklärung. Ohne Windows-API laufen auch keine Exen

Ich kann ehrlichgesagt deine Aufregung auch nicht nachvollziehen. .NET und Java sind riesig wenn man sie mit Python vergleicht. Nervig ist nur, dass logischerweise immer nur ein Interpreter den .py Dateien zugeordnet ist.

Würde Python sich standardmässig im Pfad integrieren(und nicht python.exe heissen), oder Verknüpfungen unter pythonXY im Winodows System-Order anlegen, dann könntest du einfach eine *.bat Datei erstellen und über pythonXY dein Programm ausführen.

[ms4py]

Würde Python sich standardmässig im Pfad integrieren(und nicht python.exe heissen), oder Verknüpfungen unter pythonXY im Winodows System-Order anlegen, dann könntest du einfach eine *.bat Datei erstellen und über pythonXY dein Programm ausführen.

Ach, das kann man auch kurz selber scripten. Mit os.listdir im Windows-Laufwerk nach PythonXY suchen, in jedem eine pythonXY.bat anlegen und den Ordner zu PATH hinzufügen.

Oder noch einfacher alle pythonXY.bat in einem Verzeichnis anlegen, der schon in PATH ist. Dann entfällt das lästige Registry-Manipulieren. Dann ist das ein Script mit ca. 5 Zeilen

[Leonidas]

Ja, das kann man. Der Punkt ist aber, warum das nicht automatisch passiert, wie unter Unices.

Eine Erklärung wäre, dass unter Windows %PATH% eh nicht so wichtig ist weil "alle" sowieso GUI-Programme nutzen.

[syntor]

Es ist aber wichtig, um einfach aus der Kommandozeile oder über <Win>-<R> ein Python-Script mit Hilte eines bestimmten Interpreters auszuführen.

Zudem kannst du nicht bloss die Pfade der Python Installationen zu %PATH% hinzufügen, da alle Python Interpreter python.exe heissen.

[jens]

Also ich kann Costi schon verstehen. Eine bessere Lösung wäre wirklich schön. Aber ich persönlich brauche es nicht

IMHO liegt der Fokus bei der Python Entwicklung weniger auf Windows und offensichtlich gibt es nicht genug Leute, die Python Programme für Windows anbieten und als Zielgruppe "Otto Normalanwender" haben... Ansonsten würde es anständige Lösungen geben.

Windows braucht halt einen Paketmanager, wie Linux. Das ist ein großer Pluspunkt für Linux.

[Xynon1]

Och legt euch die Pfade doch als Umgebungsvariablen ab, dann müsst ihr in der Konsole halt %python2% schreiben

Windows braucht halt einen Paketmanager, wie Linux. Das ist ein großer Pluspunkt für Linux.

Seit wann hat jede Linux-Distribution einen Paketmanager ?

[funkheld]

Du musst Python 3 ja nicht benutzen wenn Dir die 2er im Moment noch besser gefällt.

Das geht auch nicht, wenn man viele Python-Zusatzsoftware benutzt.

Innerhalb von 6 Monaten müsste es doch drin sein die ganze Scheisse zu ersetzen für 3....
Mannometer....

[querdenker]

@funkheld: Mario Barth: ....Ahnung....Fresse....

Oder auch: Unter 100 Besserwissern gibt 1 Bessermacher.

Mit anderen Worten: Pack die Axt ein, komm aus dem Wald, zieh den Stöpsel aus dem A.... und lass Luft ab, setz dich an deinen Rechner und fang an die Module zu portieren.
Danach kannst du dich zu deiner Aussage

Innerhalb von 6 Monaten müsste es doch drin sein die ganze Scheisse zu ersetzen für 3

ja gerne äußern.
Ich habe da schon eine Wunschliste:

• wxPython
  pyQT oder pyside
  kinterbasdb

Da das ja nur ein paar Module sind hätte ich die gerne bis Ende März von dir auf 3.xx portiert.

Danke im voraus.

[BlackJack]

@funkheld: Was meinst Du mit Zusatzsoftware und wieso geht das nicht? Python 2.7 ist eine offizielle *aktuelle* Python-Version und es wird die auch noch länger geben. Wenn Du Python 3 noch nicht ausreichend unterstützt siehst, dann ist das *Deine* Entscheidung ob Du auf eine aktuelle 2er wechselst oder vielleicht auch eine ganz andere Programmiersprache einsetzt.

Eine Migration von allen Programmen und Bibliotheken, die in Python geschrieben sind, in 6 Monaten ist ganz sicher *nicht* realistisch machbar. Das gilt auch für jede andere verbreitete Programmiersprache.

Meine Zielplattform sind hauptsächlich Rechner auf denen ein "stabiles" Linux läuft, dass vom Distributor bis 2015 in dieser Konfiguration unterstützt wird. Da drauf ist Python 2.6 als Standardpython installiert. Damit habe ich wahrscheinlich bis 2014 keine grosse Motivation irgend etwas von der bestehenden Codebasis nach Python 3.x zu portieren. Das macht mir zum jetzigen Zeitpunkt nur Arbeit ohne erkennbaren Mehrwert. Und ich bin ganz sicher nicht der Einzige in dieser oder zumindest ähnlicher Situation.

In die andere Richtung muss ich aber ein paar Sachen kompatibel zu 2.5 halten, weil es mit Jython ausführbar sein muss. Und PyPy finde ich als in die Zukunft gerichtete Entwicklung ganz interessant -- die sind aber auch noch bei 2.5.