Shell-Umgebung für Virtualenv / Virtualenvwrapper einrichten

3452
hute37

Die Frage betrifft das Shell-Setup für den virtualenvwrapper, eine Erweiterung zu virtualenv ( Python-Anleitung ).

Ähnliche Fragen wurden oft gestellt, jedoch mit vielen unterschiedlichen Antworten:

Dies ist der "beste" Weg, um das Setup der Umgebung und das Funktionsdefinitionsskript auszulösen, wobei mehrere mögliche Optionen in Betracht gezogen werden:

  1. ~ / .profile
  2. ~ ./. bash_profile, ~ / .zprofile
  3. ~. / bash_login, ~. / zlogin (esoterische Option)
  4. ~ / .bashrc, ~ / .zshrc

Der Leitfaden zum Virtualenvwrapper lautet:

"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.

Sehen

für non-bash / zsh / ksh-Ausschluss.


In X-Anmeldungen funktioniert ~ / .profile für (manuelle) Umgebungseinstellungen:

export WORKON_HOME=~/.virtualenvs export ENV_NAME='myvirtualenv' export VIRTUAL_ENV="$WORKON_HOME/$ENV_NAME" export PATH="$VIRTUAL_ENV/bin:$PATH" unset PYTHON_HOME 

Die Definition der Virtualenvwrapper-Funktion funktioniert nicht.

source `which virtualenvwrapper.sh` 

Eine Alternative könnte sein, alles in ~ / bashrc zu setzen

export WORKON_HOME=~/.virtualenvs export ENV_NAME='myvirtualenv' source `which virtualenvwrapper.sh`  workon $ENV_NAME 

Aber das funktioniert auch nicht:

  1. 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.
  2. Die Umgebung, die von einem Prozess (Emacs) festgelegt wird, wird durch das Überschreiben von ~ / .bashrc zerstört

Ein Beispiel:


Eine bessere Option könnte eine gemischte Lösung sein (nicht so cool ...)

In ~ / .profile, manuelle Umgebungseinstellung

export WORKON_HOME=~/.virtualenvs export ENV_NAME='myvirtualenv' export VIRTUAL_ENV="$WORKON_HOME/$ENV_NAME" export PATH="$VIRTUAL_ENV/bin:$PATH" unset PYTHON_HOME 

Fügen Sie in ~ / .bash_profile oder ~ / .zprofile das POSIX-Profil und die Funktionsdefinition ein:

[ -f ~/.profile ] && source ~/.profile [ -f `which virtualenvwrapper.sh` ] && source `which virtualenvwrapper.sh` 

In gnome-terminal werden durch Aktivieren der Option "login-shell" die "workon" -Funktionen definiert.

Für die Remote-Ausführung ist es möglich, den Profileinschluss auf folgende Weise auszulösen:

ssh localhost bash --login -c env 

Möglicherweise könnte etwas Ähnliches für systemd und cron aufgerufen werden.

Sehen:


All diese Konfigurationssachen sehen hässlich aus und sind schwer zu warten. Ist eine bessere Lösung möglich?

2
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:

Vielleicht ist ein "Re-Hash" erforderlich ...

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