A questão é sobre a configuração de shell para virtualenvwrapper , uma extensão para virtualenv ( guia python ).
Perguntas semelhantes foram feitas muitas vezes, mas com muitas respostas diferentes:
Qual é a maneira "melhor" de acionar a configuração do ambiente e o script de definição de função, considerando várias opções possíveis:
- ~ / .profile
-
~ ./. bash_profile , ~ / .zprofile
-
~. / bash_login , ~. / zlogin (opção esotérica)
-
~ / .bashrc , ~ / .zshrc
O guia virtualenvwrapper afirma:
"Adicione três linhas ao seu arquivo de inicialização do shell (.bashrc, .profile, etc.) para definir o local onde os ambientes virtuais devem viver"
Antes de considerar as opções disponíveis, é importante considerar possíveis "Casos de uso" :
- login do terminal (console) (sem X, localmente)
- login remoto ssh (interativo)
- execução do comando remoto ssh (não interativo)
- após um login "gráfico" (GDM), abrindo um terminal (gnome-terminal)
- diretamente no DE (Gnome), via invocação Exec do arquivo "desktop"
- indiretamente chamado de xclient (por exemplo, subprocesso do emacs)
- declarado como trabalho cron para o usuário
- registrado como serviço systemd (ou soquete) para usuário não raiz
- indiretamente iniciado por um subprocesso de serviço (por exemplo, httpd CGI)
Para suportar o login gráfico X, a única maneira de definir o caminho é por meio de ~ / .profile , que obtém fontes por meio de / etc / gdm / Xsession , depois de / etc / profile
Embora este seja o melhor local para definição de caminho e ambiente, ele não consegue definir corretamente funções virtualenvwrapper ( "workon" )
O motivo é que o Xsession é executado sob o shell POSIX / bin / sh ,
que não é suportado pelo virtualenvwrapper (bash, zsh, ksh support)
Algumas distro adotaram traço como shell POSIX, enquanto outras ainda dependem da invocação bash no modo POSIX.
Veja
para exclusão não bash / zsh / ksh.
Em X logins, o uso de ~ / .profile para configurações de ambiente (manuais) funciona:
export WORKON_HOME=~/.virtualenvs
export ENV_NAME='myvirtualenv'
export VIRTUAL_ENV="$WORKON_HOME/$ENV_NAME"
export PATH="$VIRTUAL_ENV/bin:$PATH"
unset PYTHON_HOME
a definição da função virtualenvwrapper não funciona;
source 'which virtualenvwrapper.sh'
Uma alternativa poderia ser colocar tudo em ~ / bashrc
export WORKON_HOME=~/.virtualenvs
export ENV_NAME='myvirtualenv'
source 'which virtualenvwrapper.sh'
workon $ENV_NAME
Mas isso também NÃO FUNCIONA:
- O X (gnome-shell) não é inicializado, portanto, os arquivos .desktop executam o comando com o ambiente "system", não o virtual.
- o ambiente definido por algum processo (emacs) é destruído por uma substituição ~ / .bashrc
Um exemplo:
Uma opção melhor poderia ser uma solução mista (não tão legal ...)
Em ~ / .profile , configuração manual do ambiente
export WORKON_HOME=~/.virtualenvs
export ENV_NAME='myvirtualenv'
export VIRTUAL_ENV="$WORKON_HOME/$ENV_NAME"
export PATH="$VIRTUAL_ENV/bin:$PATH"
unset PYTHON_HOME
Em ~ / .bash_profile ou ~ / .zprofile , inclua o perfil POSIX e a definição de função:
[ -f ~/.profile ] && source ~/.profile
[ -f 'which virtualenvwrapper.sh' ] && source 'which virtualenvwrapper.sh'
No gnome-terminal, habilitando a opção "login-shell" , as funções "workon" são definidas.
Para a execução remota, é possível acionar a inclusão de perfil dessa maneira:
ssh localhost bash --login -c env
Talvez algo semelhante possa ser feito para a chamada systemd e cron .
Veja:
Todo esse material de configuração parece feio e difícil de manter.
É possível uma solução melhor?