Das deutsche Python-Forum

Hi,

ich habe eine Virtuelle Umgebung erzeugt, nennen wir sie VENV1. In dieser habe ich ganz brav mit pip alle benötigten Module installiert, u.a. juypter notebook.
In meiner Einfalt habe ich nun gedacht, wenn ich die virtuelle Umgebung im Ganzen kopiere, sagen wir mal, nach VENV2, dass ich dann alle erforderlichen Dinge dabei (ich habe nichts Besonderes gemacht, also nichts, was irgendwelche spezielle Soft- oder Hardware erfordert). (konkret hatte ich es auf einen anderen Rechner kopiert, aber da das nicht funktioniert hat, habe ich zu Testzwecken auf meinem Rechner das Verzeichnis einfach umbenannt)

Also habe ich versucht, am "neuen" Ort das Notebook zu starten. Also Command- Prompt geöffnet, Virtuelle Umgebung aktiviert - Versuch gescheitert, weil in der activate.bat der Pfad hart drin steht.
Habe die Datei dann von Hand angepasst, activate läuft nun anscheinend durch.

Aber wenn ich starte, kommt die folgende Fehlermeldung
Was muss ich noch tun, damit er die Python- Umgebung nicht im alten Verzeichnis sucht?
Habe ich einen grundlegenden Denkfehler?

Venvs sind grundsätzlich nicht kopier- oder verschiebbar. Die Doku hat da auch eine schöne rote Warnung zu: https://docs.python.org/3/library/venv. ... venvs-work Da steht dann auch gleich noch die richtige Vorgehensweise: Einfach eine neue venv erstellen.

Das geht so nicht. Venvs sind nicht beweglich. Du kannst eine requirements.txt erstellen, die am Einsatzort in einem neuen venv wieder die gleichen Verhältnisse herstellt.

Alternativ kannst du sowas wie pyinstaller benutzen.

ausgesprochen ärgerlich Es hätte so leicht sein können.
Bei "normaler" Softwareentwicklung kommt letztlich eine exe (oder etwas vergleichbares für Linux/Mac) raus, die ich einfach weitergeben kann, ohne dass der andere sich um irgendwelche Installationen kümmern muss. Bei Python muss dann die Tippeltappeltour gewählt werden. Wenn ich ein Jupyter- Notebook, das ganz tolle Sachen macht, weitergeben will, muss der andere Python explizit installieren, eine virtuelle Umgebung einrichten, in dieser alle Module laden und DANN kann er mein Notebook sehen...
Und das, obwohl in der Virtuellen Umgebung ALLE erforderlichen Komponenten schon drin sind: Die passende Python- Version, die notwendigen Bibliotheken (ich weiß, wenn ein Oracle- Client gebraucht wird, dann ist der im System installiert. Das ist aber bei einer "gewöhnlichen" exe auch nicht anders, dass teilweise man auf eine bestimmte Hard- oder Software- Situation aufsetzt.)
Ärgerlich, ausgesprochen ärgerlich. Da ergibt sich für mich die Frage, ob ich in meinem Umfeld überhaupt mit virtuellen Umgebungen arbeiten sollte. Es wäre leichter, einmal überall eine definierte Umgebung zu schaffen und dann einfach die Notebooks weiterzureichen.

Vielen Dank für die klaren Worte

@PyGuest: Python ist im venv nicht drin, da sind links auf Python drin. Und auch Python-Programme kann man in eine EXE verpacken in der alles drin ist.

Umgekehrt wäre es IMHO ärgerlich wenn man für ein Jupyter-Notebook immer alles mitgeliefert bekommen würde, obwohl man eigentlich nur das Notebook auf den einen Server, den man sich dafür mal eingerichtet hat, hochladen wollte. Vor allem die Frage wie man dieses Notebook dann aus einer EXE heraus bekommt. Die auf Linux und MacOS auch gar nicht läuft.

Ich habe mal in all meine Virtuellen Umgebungen hineingeschaut. In jeder gibt es im Scipts- Verzeichnis eine python.exe. Aber diese ist recht klein, der eigentliche Code steckt wahrscheinlich in der dll im Installationspfad. Das war wohl mein Denkfehler.

Nun gut, also zurück von Jupyter Notebook zu QGIS. Das ist überall installiert, darauf kann ich leichter aufsetzen.

jI-yaj. qa-tlho'.
https://klingonisch.de/wissenswertes/sa ... wendungen/

Hallo,

Bei "normaler" Softwareentwicklung kommt letztlich eine exe (oder etwas vergleichbares für Linux/Mac) raus, die ich einfach weitergeben kann,

Definiere "normal"... Bei Python ist das alles normal. Wenn du für dich als "normal" definierst, dass ootb wie bei z.B. Go oder C alles in eine Datei kompiliert werden kann - ja, dann ist Python (und jede andere Interpretersprache) nicht normal.

Der "normale" Weg, Python-basierte Software zu verteilen ist ein Python-Package zu bauen (ist in der Python-Doku erklärt) und das dann z.B. via PyPi zu verteilen. Bzw. dann kann es jeder via pip in eine Verzeichnis seiner Wahl - mit oder ohne venv - installieren. Wenn Python auf dem Rechner installiert ist.

Gruß, noisefloor

Vor allem ist das auch bei "normaler" Softwareentwicklung ausser fuer wirklich die simpelsten Programme nicht so. Der Aufwand, der in einen Installer, oder mindestens mal das build-system geht, wenn dann zB Resourcen eingebettet werden muessen, etc. pp, ist nun auch nicht substantiell geringer als pyinstaller zu benutzen.

Mit "normaler" Softwareentwicklung meinte ich Software, die für einen "Endverbraucher" produziert wird. Jemand, der keine Ahnung von Programmieren, Installieren und Paketen hat, der letztlich eine "Anwendung" startet, die ihm die Funktionen zur Verfügung stellt, die er benötigt. Ja, die Idealvorstellung ist, dass nur eine Datei herauskommt. Zweitbeste Variante ist, dass ein Verzeichnis irgendwo hin kopiert wird. Und die drittbeste Variante ist, dass irgendein Installer von irgendeinem Admin aufgerufen wird (der von der Software aber idealerweise auch keine Ahnung hat).
Bei Python muss auch der Admin zumindest soviel von Softwareentwicklung verstehen, dass er die Pakete mit irgendeinem Paketmanager nachinstalliert, der eindeutig ein Werkzeug des Softwareentwicklers ist.

Zum Thema "simpelste Programme": Man kann mit den Bordmitteln des Systems schon eine Menge erreichen und nicht nur "simpelste Software" schreiben. Hinzu kommt, dass auf dem System ja durchaus auf bereits installierte Komponenten zugegriffen werden kann, ohne dass sie Bestandteil des Installers der Anwendung sind.

Aber egal, ich will mich nicht streiten. Mein Umfeld bilden Kollegen, die keine Zeit und auch keine Lust haben, sich mit den Werkzeugen eines Softwareentwicklers zu beschäftigen. Daher muss ich meine Tools anders bereitstellen
- eine EXE, die idealerweise nicht installiert werden muss
- als QGIS- Plugin, da QGIS sowieso installiert ist
- als Web- Anwendung
Die erste Variante klappt leider nicht so richtig mit Python (vermutlich schon, aber meine Versuche damit blieben leider erfolglos. Eine 0815- Anwendung mit Bordmitteln ging noch, aber spätestens, als ich eine Verbindung zur Oracle- DB aufbauen wollte, ging das schief. Lag sicher an mir, aber mehr Zeit in die Untersuchung konnte ich damals nicht investieren)
Die anderen beiden Varianten sind natürlich noch ein Schritt mehr für mich, aber da muss ich wohl durch.

Ich möchte nicht den Python- Löwen in Euch wecken, ihr müsst Python nicht verteidigen. Ich nutze es gern, es ist sehr mächtig. Aber das Bauen von Endbenutzeranwendungen empfinde ich halt als deutlich aufwändiger, als mit einer Rundum- Sorglos- IDE, wie beispielsweise Lazarus. Dafür gibt es für Lazarus eben deutlich weniger mächtige Bibliotheken. Muss halt im Einzelfall eine Abwägung treffen, was ich wie mache.

Hallo,

für die gewünschte *.exe wurde schon PyInstaller genannt. Das etwas Benutzer-/Anfängerfreundlich findet man mit Auto-py-2-exe


Grüße
Dennis

Hallo,

wenn man keine Lust hat, Software wie auch immer geartet zu verteilen -> Webanwendung. Den Weg gehe ich zumindest mit der Software, die meine Kollegen auch nutzen. Webanwendungen kann man ganz hervorragend mit Erstellen -> z.B. mit dem Django Webframework.

Der allgemeine angenehme Seiteneffekt: es nutzen immer alle die neuste Version, weil halt nur die online ist. Selbst wenn du deine Software als einzelnes Executable Binary verteilst kannst du das nicht sicherstellen. Jedenfalls nicht ohne Installer.

Gruß, noisefloor

PyGuest hat geschrieben: Mittwoch 17. Januar 2024, 19:56 Mit "normaler" Softwareentwicklung meinte ich Software, die für einen "Endverbraucher" produziert wird. Jemand, der keine Ahnung von Programmieren, Installieren und Paketen hat, der letztlich eine "Anwendung" startet, die ihm die Funktionen zur Verfügung stellt, die er benötigt.

Auf sowas habe ich mich bezogen. Der ehemalige Arbeitgeber hat Millionen Endkunden als Benutzer. Und in die Infrastruktur und Installer sind Mannjahre geflossen. Wenn entsprechend viel an Assets, Bibliotheken, Hilfedateien, Auto-Update-Systemen etc benötigt werden, damit der Endbenutzer nur noch den sprichwörtlichen Doppelklick braucht, ist es eben nicht so einfach. Jedenfalls nicht mit C++, nicht unter Windows, nicht unter dem Mac. Und das sind sicher 80% wenn nicht mehr aller „traditionellen“ Programme.

Man kann sich ja immer viel wünschen, aber das es da draußen eine solche eierlegende Wollmilchsaue geben würde, wäre mir neu. Lazarus kann ich da auch nicht sehen - ich habe einmal probiert damit was zu machen, und da musste die IDE sich als Ganzes neu übersetzen, weil ich eine Abhängigkeit für das zu erstellende Programm brauchte. Wildes Konzept, aber prinzipiell mir egal. Hat aber dann natürlich auch nicht funktioniert. So wie du eben mit pyinstaller keine Oracle Verbindung auf Anhieb zustande bekommen hast. Ist halt alles immer nerviger Mist.

Du kannst ja ansonsten einmal schauen, ob "shiv" etwas für dich ist. Zum Ausführen unter Windows muss immer noch einmalig ein Python-Interpreter installiert werden, aber das ist bei Java etc. ja nicht groß anders. Exe-Dateien aus eher unklaren bis zweifelhaften Quellen (einschließlich dem netten Kollegen aus der anderen Abteilung) gehen unter Sicherheitsaspekten eigentlich gar nicht.

Also wenn das ausreicht was mit dem Python von qgis möglich ist, dann scheint mir ein qgis-plugin als die einfachste Möglichkeit.

Vorausgesetzt dieses 5 Jahre alte Minimal-Plugin qgis-minimal-plugin funktioniert auch heute noch.
Projektverzeichnis im qgis-Pluginverzeichnis anlegen, zwei Dateien rein kopieren und schon kann es offenbar losgehen...
Zur Oracle-Verbindung sage ich jetzt nichts... ich kenne qgis nicht und mit Oracle-Datenbanken hatte ich noch nie Kontakt

nezzcarth hat geschrieben: Mittwoch 17. Januar 2024, 22:22 Du kannst ja ansonsten einmal schauen, ob "shiv" etwas für dich ist.

Bin zwar nicht der TE, aber auf jeden Fall ein interessantes Konzept:

Instead of shipping our binary with downloaded wheels inside, we package an entire site-packages directory, as installed by pip. We then bootstrap that directory post-extraction via the stdlib’s site.addsitedir function. That way, everything works out of the box: namespace packages, real filesystem access, etc.

Because we optimize for a shorter sys.path and don’t include pkg_resources in the critical path, executables created with shiv can outperform ones created with PEX by almost 2x. In most cases the executables created with shiv are even faster than running a script from within a virtualenv!

https://shiv.readthedocs.io/en/latest/history.html#how

Da werden die Abhängigkeiten wohl nicht direkt als Modulcode mitgeschleppt, sondern beim Starten via pip nachinstalliert, falls nötig.

Gucke ich mir später wahrscheinlich nochmal in Ruhe an, sieht jedenfalls spannend aus.

Weiß gar nicht, was du hast.
Bei Linux ist Python schon direkt installiert.

Kebap hat geschrieben: Donnerstag 18. Januar 2024, 10:32 Bei Linux ist Python schon direkt installiert.

Beim Endkunden aber wahrscheinlich nicht. Die meisten nutzen auf dem Desktop leider immer noch Windows. Bei Steam sind es gerade mal ~2% Linux-Nutzer und der Zuwachs von 0,15 % bei Arch Linux kam durch den Steam Deck zustande.

Quelle: https://store.steampowered.com/hwsurvey ... e-to-Steam


Falls möglich könnte man PyInstaller verwenden und wenn man einen Installer wünscht, dann z.B. NSIST oder gleich pynsist.

https://pyinstaller.org/en/stable/
https://sourceforge.net/projects/nsis/
https://pypi.org/project/pynsist/

Letztes (pynsist) installiert eine Python-Version mit, wenn ich mich noch richtig erinnere. PyInstaller ist dann wahrscheinlich überflüssig.

Hallo,

BTW: wer das Microsoft Store installiert hat (ist AFAIK ootb bei Win dabei), der kann darüber Python installieren - verschiedene Versionen (AFAIR alle mit Support) parallel und direkt von der PSF bereitgestellt. Das ist sogar noch einfacher als unter Linux.

Gruß, noisefloor

noisefloor hat geschrieben: Donnerstag 18. Januar 2024, 15:10 BTW: wer das Microsoft Store installiert hat (ist AFAIK ootb bei Win dabei), der kann darüber Python installieren - verschiedene Versionen (AFAIR alle mit Support) parallel und direkt von der PSF bereitgestellt. Das ist sogar noch einfacher als unter Linux.

So ist es. Hier eine Übersicht zu den verfügbaren Python-Versionen:
https://winstall.app/apps?q=publisher:% ... Foundation

Installieren geht dann über das für die jeweilige Version hinterlegte Kommando, z. B.: Das geht dann als Benutzer-Installation, man benötigt keine Admin-Rechte.

Somit könnte man die Python-Installation bei Bedarf auch ziemlich easy in einem Skript hinterlegen. Es bräuchte nicht mal Kenntnisse über MSI-Files.