konfiguracja środowiska powłoki dla virtualenv / virtualenvwrapper

Pytanie dotyczy konfiguracji powłoki dla virtualenvwrapper , rozszerzenia do virtualenv ( przewodnik po pythonie ).

Podobne pytania zadawano wiele razy, ale z wieloma różnymi odpowiedziami:

• Zmienne środowiskowe w bash_profile czy bashrc?

• Różnica między .bashrc i .bash_profile

Który jest „najlepszym” sposobem na uruchomienie skryptu konfiguracji środowiska i definicji funkcji, biorąc pod uwagę kilka możliwych opcji:

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

Przewodnik virtualenvwrapper stwierdza:

„Dodaj trzy wiersze do pliku startowego powłoki (.bashrc, .profile itp.), Aby ustawić lokalizację, w której powinny mieszkać środowiska wirtualne”

Przed rozważeniem dostępnych opcji należy rozważyć możliwe „przypadki użycia” :

• logowanie do terminala (konsoli) (bez X, lokalnie)
• zdalne logowanie ssh (interaktywne)
• zdalne wykonywanie poleceń ssh (nieinteraktywne)
• po „graficznym” zalogowaniu (GDM), otwarciu terminala (terminal gnome)
• bezpośrednio w DE (Gnome), poprzez wywołanie Exec pliku „na pulpicie”
• wywoływane pośrednio z xclient (np. podproces emacsa)
• określone jako zadanie cron dla użytkownika
• zarejestrowany jako usługa systemowa (lub gniazdo) dla użytkownika innego niż root
• pośrednio uruchomiony przez podproces usługi (np. httpd CGI)

W celu obsługi graficznego logowania X jedynym sposobem ustawienia ścieżki jest ~ ~ .profile , który pobiera źródła przez / etc / gdm / Xsession , po / etc / profile

Chociaż jest to najlepsze miejsce dla ustawienia ścieżki i środowiska, nie można poprawnie zdefiniować funkcji virtualenvwrapper ( „workon” )

Powodem jest to, że Xsession jest wykonywany pod powłoką POSIX / bin / sh , która nie jest obsługiwana przez virtualenvwrapper (obsługa bash, zsh, ksh)

Niektóre dystrybucje przyjęły myślnik jako powłokę POSIX, podczas gdy inne nadal polegają na wywołaniu bash w trybie POSIX.

Widzieć

• https://github.com/brainsik/virtualenv-burrito/issues/8

dla wykluczenia nie bash / zsh / ksh.

W logowaniach X użycie ~ / .profile dla (ręcznych) ustawień środowiska działa:

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

definicja funkcji virtualenvwrapper nie działa;

source `which virtualenvwrapper.sh`

Alternatywą może być umieszczenie wszystkiego w ~ / bashrc

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

workon $ENV_NAME

Ale to NIE DZIAŁA również:

1. X (gnome-shell) nie zostaje zainicjowany, więc polecenie .desktop files exec wykonuje się w środowisku „systemowym”, a nie wirtualnym.
2. środowisko ustawione przez jakiś proces (emacs) jest niszczone przez przesłonięcie ~ / .bashrc

Przykład:

• https://github.com/jorgenschaefer/elpy/issues/538

Lepszym rozwiązaniem może być rozwiązanie mieszane (nie tak fajne ...)

W ~ / .profile , ręczne ustawienie środowiska

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

W ~ / .bash_profile lub ~ / .zprofile , dołącz profil POSIX i definicję funkcji:

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

W gnome-terminal, po włączeniu opcji „login-shell” , definiowane są funkcje „workon” .

W celu zdalnego wykonania możliwe jest włączenie włączenia profilu w następujący sposób:

ssh localhost bash --login -c env

Być może coś podobnego można zrobić dla wywołania systemd i cron .

Widzieć:

• https://gist.github.com/BerraDev/22a7216a5e1e16bcc2c2

Wszystkie te elementy konfiguracji wyglądają brzydko i są trudne w utrzymaniu. Czy to możliwe lepsze rozwiązanie?

Ale w końcu dlaczego virtualenv powinien być aktywny w kontekście globalnej powłoki gnome ?

Z pewnością spowodowałoby to uszkodzenie wszystkich zainstalowanych aplikacji Python na poziomie systemu .

Tak więc jedynym bezpiecznym sposobem na uruchomienie aplikacji virtualenv jest uruchomienie z powłoki terminala

Prawdopodobnie bezpieczniej jest aktywować środowisko w ~ / .bash_profile ~ / .zprofile , włączając opcję powłoki logowania w terminalu.

Należy unikać alternatywnego ustawienia, używając ~ / .bashrc , ponieważ może to powodować problemy w podpowłokach.

Więc,

• włącz opcję logowania
• uruchom terminal (lub bash / zsh --login w xterm ...)
• "pracować nad"
• następnie uruchom emacs (serwer) z powłoki terminala.

Aby uruchomić aplikację virtualenv z gnome-shell , plik na pulpicie musi wykonać dedykowany skrypt otoki, który źródło env aktywuje przed wykonaniem.

W celu uzyskania ogólnego opakowania (podobnego do ruby „bundle exec” i rvm) zobacz:

• https://gist.github.com/datagrok/2199506

Być może wymagane jest „ponowne hashowanie” ...

• https://github.com/pypa/virtualenv/blob/develop/virtualenv_embedded/activate.sh#L76