Deployment von Python4Delphi Programm

[BastiFantasti]

Hallo zusammen,

ich versuche mich gerade an der Integration von Python4Delphi.
Auf meinem Entwicklungsrechner mit installiertem Python inklusive PyEnv funktioniert das Integrieren und Ausführen wunderbar.
Auch der Einsatz von venvs funktioniert.

Jetzt wollte ich zu Testzwecken die Anwendung in einer "nackten Win10 VM" ohne installiertem Python testen.

Ich habe die benötigte Python310.dll mit ins Anwendungsverzeichnis kopiert und das TPythonEngine Objekt dynamisch erzeugt.

Code:

    
    pe1 := TPythonEngine.Create(nil);
    pe1.AutoFinalize := False;
    pe1.UseLastKnownVersion := False;
    pe1.RegVersion := '3.10';
    pe1.DllName := 'python310.dll';
    pe1.DllPath := '.\';
    pe1.IO := pyguiIO1;
    pyDVar1.ClearEngine;
    pyDVar1.Engine := pe1;
    pe1.LoadDll;

bei dem DllPath habe ich auch wahlweise das tatsächliche Anwendungsverzeichnis angegeben - mit gleichem Ergebnis.

Beim Start kommt nun die Meldung, dass die Python310.dll nicht geladen werden kann. Das Programm beendet sich dann automatisch wieder.

Dann hab ich mir gedacht, ob es noch externe Abhängigkeiten gibt...
Tatsächlich benötigt Python 3.10 unter Windows wohl die Visual C++ Runtime v14 (2015).

Seit ich die Runtime in der VM installiert habe, startet die Anwendung gar nicht mehr - es hat also scheinbar etwas bewirkt

Wie habt ihr das Deployment Problem gelöst?

Viele Grüße
Bastian

[himitsu]

Nur die Python-DLL einzeln geht nicht.
Was du suchst ist das Python-Embedded.

Geh zu https://www.python.org/downloads/windows/
und besorg dir eine ZIP (Windows embeddable package 32-bit, für dein 32 Bit-Delphiprogramm)
Die Visual C++ Runtime ist dort mit enthalten.

Diese entpacken (Dateien müssen nicht im Programmverzeichnis liegen ... Unterverzeuchnis geht auch, oder daneben oder sonstwo)

Und dann im Python4Delphi die python3.dll oder z.B. explizit die python38.dll angeben und laden.

Will man zusätzlich noch PIP benutzen, dann muß man sich Dieses runterladen (als pip.pyz oder als Modul/Verzeichis innerhalb des Verzeichnisses)
sowie den PY-Script-Suchpfad im python38._pth hinzufügen, und optional auch noch noch den Suchpfad (%PATH%) auf \Scripts.

[BastiFantasti]

Super!

Vielen Dank für die schnelle und ausführliche Antwort.
Ich werde das nachher gleich testen und mich hier wieder melden.

Viele Grüße
Bastian

[BastiFantasti]

Erstellst du das TPythonEngine Objekt als visuelle Komponente oder in einem Event beim Start der Anwendung?

[himitsu]

Ach ja, die "automatische" Suche, nach der aktuellen/neusten Version, funktioniert nur beim installierten Python.

Wir haben uns die Suche für das Embedded selbstgebaut. (damit wir nicht unbedingt im Programm was ändern müssen, wenn wir ein neues Python ins Verzeichnis schieben)

Also sie automatische Suche deaktiviert und dann die Python-DLL mit absolutem Pfad beim Python4Delphi angeben.
Aber zumindestens kann man statt python310.dll auch einfach python3.dll benutzen, was eine Umlautung zur aktuellen python3*.dll darstellt (jeweils auf die aktuelle Version der ZIP bezogen)

[himitsu]

Ich bin aktuell dabei mit PIP zu spielen ... funktioniert eigentlich gut,
aber neue Scripte mit Modulen/Imports, welche eigene .PYD und .DLL laden, bereiten Probleme.

Zuerst visuell rumgespielt
und dann alles in eine Komponente veeschoben. (inkl. Variablen von Inhalten aus der aktuellen Form, sowie Durchreichen von Delphi-Funktionen ins Python, bevor das Script ausgeführt wird)
Im Prinzip reicht so minimal eine Funktion, welcher ich die akktuelle Form und das Python-Script als String übergebe und einen String zurückbekomme.

Und, damit zwischen den Scripten keine Dinge durchwandern, hatten wir uns damals entschlossen das Python nach jeder Ausführung zu beenden und die DLL zu entladen,
damit keine Variablen und geladenen/benutzen Klassen von einer Script-Ausführung ins nächste Script kommen.
Wir hatten es nicht hinbekommen ein Reset zu implementieren und das war die schnellste Lösung. (auch das Laden/Entladen der zwei DLLs (python38.dll und vcruntime140.dll geht enorm ausreichend schnell)
PS: 3.8, da wir mit unseren jahrzehntealten Sctipten (damals noch über die Python.exe des Embedded-Python) in der 3.10 Probleme haben. (und keine Lust/Zeit ALLE Scripte umzubauen und zu prüfen, auch fremde Scripte bei vielen unserer Kunden)

Das ging bisher gut, aber Script-Entwickler und auch die Python-Entwickler sind Schweine, welche nicht wirklich an eine Embedded-Nutzung dachten .... also Vieles einfach garnicht wieder freigeben. (das Beenden der Python-EXE erledigt das ja normalerweise, aber siehe meine Signatur )

Wie ich geladene DLL/PYD ordentlich entladen kann, weiß ich inzwischen (hat 'ne Woche Arbeit und zu viele graue Haare gekostet, aber Windows sagt mir nun endlich, welche DLLs geladen wurden, in welcher Reihenfolge und warum, also ob z.B. durch manuelles LoadLibrary, eine statische Verlinkung, sowie DelayedLoading und Anderes).
Aber z.B. beim PySide bleibt dennoch ein Speicherleck von 9-11 MB und selber vorher (war aber grade erst aufgefallen) war schon ein 3-4 MB Leck vorhanden gewesen.
(wir wollten nun eigentlich Python mehr verwenden, aber wenn nach 100 Ausführungen plötzlich 300 bis 1000 MB RAM verschwinden, ist das in Win32 schon bissl blöd, selbst mit der 4GB-Erweiterung)

[BastiFantasti]

Ja das mit dem Speicherleck klingt in der Tat problematisch ...

Bei Pip usw bin ich noch nicht. Noch kämpfe ich mit dem "Hello World"

Ich bin jetzt auch einen Schritt weiter.
Ich habe das Paket heruntergeladen und in ein Unterverzeichnis gepackt.
Scheinbar kann die DLL jetzt initial geladen werden.
Nun wirft er aber den nächsten Fehler: "Could not map symbol Py_DebugFlag"
obwohl ich eigentlich keine Flags in dem Konstruktur bzw. der Initialisierung der PythonEngine gesetzt habe.