Pytanie dotyczy konfiguracji powłoki dla virtualenvwrapper , rozszerzenia do virtualenv ( przewodnik po pythonie ).
Podobne pytania zadawano wiele razy, ale z wieloma różnymi odpowiedziami:
Który jest „najlepszym” sposobem na uruchomienie skryptu konfiguracji środowiska i definicji funkcji, biorąc pod uwagę kilka możliwych opcji:
- ~ / .profile
- ~ ./. bash_profile , ~ / .zprofile
- ~. / bash_login , ~. / zlogin (opcja ezoteryczna)
- ~ / .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ć
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ż:
- X (gnome-shell) nie zostaje zainicjowany, więc polecenie .desktop files exec wykonuje się w środowisku „systemowym”, a nie wirtualnym.
- środowisko ustawione przez jakiś proces (emacs) jest niszczone przez przesłonięcie ~ / .bashrc
Przykład:
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 envByć może coś podobnego można zrobić dla wywołania systemd i cron .
Widzieć:
Wszystkie te elementy konfiguracji wyglądają brzydko i są trudne w utrzymaniu. Czy to możliwe lepsze rozwiązanie?