Existe uma maneira legal de definir variáveis de ambiente locais de diretório / projeto?

4

Tenho trabalhado em vários projetos e eles exigem diferentes variáveis de ambiente (por exemplo, PATH para diferentes versões de clang executáveis, PYTHONPATH para vários módulos externos). Sempre que trabalho em um projeto, preciso modificar essas variáveis de ambiente (por exemplo, alterar .zshrc / .bashrc e source it); e às vezes esqueço e cometo erros.

Existe uma maneira / projeto que ajuda a fazer isso automaticamente, semelhante ao que virtualenv faz em Python?

    
por Hongxu Chen 24.03.2015 / 03:19

4 respostas

0

Você pode criar qualquer arquivo que desejar, não precisa ser .zshrc . Você poderia criar um script env-setup para cada projeto diferente e mantê-lo no diretório do projeto.

Se você deseja iniciar novos shells e fazer com que eles carreguem as configurações de env, você tem algumas opções:

  • Sempre inicie seus shells no diretório do projeto e tenha seu .zshrc [[ -e ./PROJECT-ENV.sh ]] && source ./PROJECT-ENV.sh (que você mantém lá). PERIGOSO : iniciar um novo shell em um diretório com conteúdo hostil executa o código que estiver no arquivo de origem.
  • .zshrc : source ~/current-project.sh . atualizar projeto atual com ln -sf "$PWD/THIS-PROJECT-ENV.sh ~/current-project.sh

Se apenas alguns comandos para cada projeto precisarem do conjunto env vars, você pode criar scripts de wrapper para eles que definam as variáveis e, em seguida, deixe seu arquivo shell rc intocado.

Outra ideia: você pode hackear algo no PROMPT_COMMAND, que é executado antes de cada aviso ser exibido. Ou anexe cd / pushd / popd escrevendo funções shell com os nomes que verificam / configuram env vars e então executam builtin cd .

    
por 19.04.2015 / 16:26
2

Yuch, muita manutenção e muita coisa individual.
Eu recomendaria colocar a maior parte do esforço em ter nomes com escopo apropriado que sejam apropriados para a plataforma, para que você possa ter todos eles o tempo todo. PYTHONPATH é um bom exemplo ... é improvável que você queira adaptá-lo para um projeto Ruby ... Você pode agrupar e marcar o grupo com comentários no .bashrc para facilitar a manutenção.
Nem sempre é possível fazer isso, ou seja, quando há conflito (além de exigir edição e não usar arquivos discretos) e, às vezes, é necessário um arquivo de configuração específico da estrutura. Uma abordagem para isso é ter a configuração de aliases para executá-los, por exemplo,

por exemplo,

alias pp='. ~/pp.setup' # For using Python
alias rb='. /rb.setup'  # For using Ruby

Você também pode criar uma função, algo como 'switcher', que usa / define uma variável e apenas alterna usando um parâmetro passado, ou apenas alterna para o que não é atual.

    
por 20.04.2015 / 16:05
1

Existem ferramentas de gerenciamento, como módulos , que permitem a modificação dinâmica do ambiente de um usuário ... embora este não seja mais desenvolvido; a última versão é de 2012

Exemplo:

$ module load gcc/3.1.1
$ which gcc
/usr/local/gcc/3.1.1/linux/bin/gcc
    
por 24.03.2016 / 16:55
0

Inspirado nas respostas de @Peter Cordes e @Michael Durrant, criei uma solução limitada e leve para o meu caso especial .

Primeiramente, deixe-me re-ilustrar meus problemas reais.

I need to use different llvm related executables (clang, llvm-config, etc) that are under project local directories, and I need to use 1 default version for general purpose (compiling, etc). I also need to need to use different python modules (llvm python bindings) inside different local directories.

Como todos os meus projetos relacionados ao llvm são construídos com estruturas de diretório semelhantes, especifico a variável de ambiente relacionada à versão llvm ( MY_LLVM_VERSION ) e adiciono os diretórios a PATH e PYTHONPATH . Eu usei uma função chamada _my_llvm_version que personaliza a variável interativamente . Como as funções só têm efeitos dentro dele, eu uso aliases para fazer o verdadeiro trabalho source . Então deixe MY_LLVM_VERSION padronizar para o meu mais comumente usado ( git ). Estes estão todos dentro de ~/.zlocal que serão originados para um zsh interativo. (O arquivo completo é aqui ). Ao obter ~/.zlocal , posso alterar PATH e PYTHONPATH de acordo com MY_LLVM_VERSION .

function _my_llvm_version() {
    available=("3.3" "3.4" "3.5" "git")
    USAGE="my_llvm_version 3.3|3.4|3.5|git"
    if [ $# -ne 1 ] || ! (( ${available[(I)${1}]} )); then
      echo "usage: $USAGE"
    fi
    MY_LLVM_VERSION="$1"
}
alias my_ll33='_my_llvm_version 3.3;source ~/.zlocal'
alias my_ll34='_my_llvm_version 3.4;source ~/.zlocal'
alias my_ll35='_my_llvm_version 3.5;source ~/.zlocal'
alias my_llgit='_my_llvm_version git;source ~/.zlocal'
: ${MY_LLVM_VERSION:=git}

Acho que deve ser mais sustentável e não invocar um shell filho. Deve ser útil adicionar a versão llvm à área PS1 , mas atualmente não preciso disso.

É claro que essa solução não é geral e não é uma solução real para minha pergunta original.

    
por 21.04.2015 / 14:32