Programm nutzt venv: wohin gehören dann die Programmdateien?

[bb1898]

Kommt mir vor wie eine ziemlich blöde Frage, nur finde ich so gut wie nichts dazu. Wenn mein Python-Programm die Python-Version nutzt, die ich in C:\program files\python312 habe, mit den Moduln im dort vorhandenen Unterverzeichnis site-packages (also das, was unter Windows einem "System-Python" am nächsten kommt), dann ist klar, dass ich mein Programm ganz sicher nicht in diesen Verzeichnisbaum stecke, sondern in ein Verzeichnis, in dem erst mal ich alle Rechte habe, ohne Administrator zu spielen, und das zweitens inhaltlich passt.

Nicht klar ist mir, wie das auszusehen hat, wenn ich für mein Programm eine virtuelle Umgebung einrichte, weil es zum Beispiel Pakete braucht, die sich mit dem Rest nicht vertragen (gilt im konkreten Fall für PyQt6 einerseits und PySide6 andererseits, so viel ich weiß). Dass die Programmdateien nicht in das venv-Verzeichnis gehören, habe ich irgendwo gelesen, finde es aber gerade nicht wieder. Umgekehrt das venv in ein Unterverzeichnis des Programmverzeichnisses zu stecken, leuchtet mir auch nicht ein, denn vielleicht kann ich ja das gleiche venv für verschiedene Programme brauchen. Also auch hier beides unabhängig voneinander halten?

Danke für guten Rat!

[kbr]

Ein virtuelles Environment bestimmt lediglich, wo sich das Python-Executable befindet und von wo die site-packages geladen werden. Wo sich deine Projekt-Dateien befinden ist davon völlig unabhängig. Ich würde venvs nicht mehrfach verwenden; ein Projekt - ein venv.

[bb1898]

Ein virtuelles Environment bestimmt lediglich, wo sich das Python-Executable befindet und von wo die site-packages geladen werden. Wo sich deine Projekt-Dateien befinden ist davon völlig unabhängig. Ich würde venvs nicht mehrfach verwenden; ein Projekt - ein venv.

Danke, dann wäre das geklärt, ich kann die Programme dort unterbringen, wo sie auch ohne venv hinkommen. Muss mich noch etwas schlauer machen, was die richtige Shebang-Zeile betrifft, aber das findet sich, glaube ich, in der Dokumentation.

[grubenfox]

Ein virtuelles Environment bestimmt lediglich, wo sich das Python-Executable befindet und von wo die site-packages geladen werden. Wo sich deine Projekt-Dateien befinden ist davon völlig unabhängig. Ich würde venvs nicht mehrfach verwenden; ein Projekt - ein venv.

ich weiß nicht so recht... oder verstehe was falsch... dann hat man z.B. fünf Projekte die SQLAlchemy nutzen (alle dieselbe Version!) und dann installiert man sich das fünf Mal in fünf venvs?
(Wenn man ungünstigerweise verschiedene Versionen eines Paketes nutzen muss, dann natürlich auch verschiedene venvs.)

[sparrow]

Ja, das macht man in der Regel so.

[Dennis89]

Hallo,

meist hat man ja doch noch die ein oder andere Bibliothek und wenn man die Projekte trennt, ist auch die „requierments.txt“ ordentlich.

Grüße
Dennis

[__blackjack__]

@grubenfox: Dann wachsen diese 5 Projekte und dann kommt eine SQLAlchemy-Version raus bei der deutlichere Änderungen am Code nötig sind, der die benutzt. Dann muss man das an allem 5 Projekten *gleichzeitig* ändern. Oder jedes Projekt hat seine eigene SQLAlchemy-Version und man kann die nacheinander auf die neue Version ziehen, während die anderen 4 Projekte weiterhin funktionieren.

Es ist auch einfacher den Überblick zu behalten, denn wenn sich mehrere Projekte ein venv teilen, müsste man bei jeder Änderung am venv überlegen, oder irgendwo extra dokumentieren, welche Projekte von der Änderung betroffen sind. Umgekehrt hat man ja oft eine requirements.txt im Projekt. Die müsste dann für alle Projekte gleich sein, die das venv benutzen.