Dies ist der "beste" Weg, um das Setup der Umgebung und das Funktionsdefinitionsskript auszulösen, wobei mehrere mögliche Optionen in Betracht gezogen werden:
"Fügen Sie der Shell-Startdatei (.bashrc, .profile usw.) drei Zeilen hinzu, um den Speicherort der virtuellen Umgebungen festzulegen."
Bevor Sie die verfügbaren Optionen in Betracht ziehen, sollten Sie mögliche "Use-Cases" berücksichtigen :
Terminal (Konsole) Login (ohne X, lokal)
ssh remote login (interaktiv)
ssh Remote-Befehlsausführung (nicht interaktiv)
nach einem "grafischen" Login (GDM) ein Terminal öffnen (gnome-terminal)
direkt in DE (Gnome), über "Desktop" -Datei-Exec-Aufruf
indirekt von xclient aufgerufen (z. B. emacs-Subprozess)
als cron-job für den benutzer angegeben
als systemd-Dienst (oder Socket) für Benutzer ohne Rootberechtigung registriert
indirekt durch einen Service-Subprozess gestartet (z. B. httpd CGI)
Um das grafische X-Login zu unterstützen, kann der Pfad nur über ~ / .profile festgelegt werden. Die Quellen werden von / etc / gdm / Xsession nach / etc / profile abgerufen
Obwohl dies der beste Ort für Pfad- und Umgebungseinstellungen ist, können die Funktionen von virtualenvwrapper ( "workon" ) nicht korrekt definiert werden.
Der Grund ist, dass Xsession unter der POSIX / bin / sh- Shell ausgeführt wird, die von virtualenvwrapper nicht unterstützt wird (bash, zsh, ksh-Unterstützung).
Einige Distributionen nahmen den Strich als POSIX-Shell an, während andere sich noch auf den POSIX-Modus des Bashaufrufs verlassen.
X (gnome-shell) wird nicht initialisiert, so dass der Befehl ".desktop files exec" in der Umgebung "System" und nicht in der virtuellen Umgebung ausgeführt wird.
Die Umgebung, die von einem Prozess (Emacs) festgelegt wird, wird durch das Überschreiben von ~ / .bashrc zerstört
All diese Konfigurationssachen sehen hässlich aus und sind schwer zu warten. Ist eine bessere Lösung möglich?
vielleicht sollte auch ** LD_LIBRARY_PATH ** in ** ~ / .profile ** vorangestellt werden
hute37 vor 8 Jahren
0
1 Antwort auf die Frage
1
hute37
Aber warum sollte virtualenv im globalen Gnome-Shell- Kontext aktiv sein?
Dies würde sicherlich alle installierten Python-Anwendungen auf Systemebene zerstören.
Der einzig sichere Weg, um eine Virtualenv-Anwendung zu starten, besteht darin, von einer Terminal-Shell aus zu starten
Wahrscheinlich ist es sicherer, die Umgebung im ~ / .bash_profile ~ / .zprofile zu aktivieren, wodurch die Option login-shell im Terminal aktiviert wird .
Die alternative Einstellung mit ~ / .bashrc sollte vermieden werden, da dies zu Problemen in Subshells führen kann.
So,
Aktivieren Sie die Login-Option
Starten Sie das Terminal (oder bash / zsh --login in xterm ...)
"workon"
Starten Sie dann Emacs (Server) von der Terminal-Shell aus.
Um eine Virtualenv-Anwendung von gnome-shell aus auszuführen, muss die Desktopdatei ein dediziertes Wrapper-Skript ausführen, das vor der Ausführung von source env aktiviert wird .
Für einen generischen Wrapper (ähnlich wie bei ruby 'bundle exec' und rvm-Material) siehe:
Mit zwei Shells (bash, zsh) kann man ** bash ** auf * "systemweit" * virtualenv in ** / usr / local / lib / pythonenvs ** und ** zsh ** auf * "user" zeigen. * virtualenv in ** ~ / .virtualenvs **. Nützlich zum Testen der Bereitstellung. Dieselbe Konfiguration könnte auf RVM angewendet werden
hute37 vor 8 Jahren
0