Deployment von Python4Delphi Programm

[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)