Gerenciando pacotes, diretórios e PATH no Unix (OSX)

2

Sou PhD em bioinformática, principalmente autodidata, e estou chegando a um ponto em que quero limpar minhas várias estruturas de diretórios (ou seja, meus dados), mas também estou pensando em como eu estou armazenando os vários pacotes de bioinformática que estou usando. Não tendo nenhum treinamento formal e tendo tido apenas um único curso Unix, ainda há muito que eu não sei que eu assumo são ensinados em "Unix 101" ou similar. Eu fiz um pouco de googling, mas eu realmente não encontrei respostas para minhas perguntas, então eu pensei em perguntar aqui. Eu estou trabalhando em um Mac, então OSX (Yosemite), se isso importa.

Quando se trata de baixar e instalar os vários pacotes que estou usando, minha solução atual é copiar o diretório completo baixado para /Users/sajber/software apenas para ter todos os arquivos, make (se aplicável; às vezes, estão prontos criados no diretório baixado) e copie os binários para /Users/sajber/bin . Em seguida, defini meu PATH para incluir /Users/sajber/bin . Eu não estou usando nenhuma forma de software de gerenciamento de pacotes, então faço tudo manualmente.

Quão "errado" é isso e como posso melhorá-lo? O que as pessoas costumam fazer, existe algum tipo de padrão?

Pensei em manter todos os pacotes em /Users/sajber/software como anteriormente, mas adicionar os pacotes individuais a PATH , como em PATH=$PATH:/Users/sajber/software/<package> . Quando eu comecei, inicialmente fiz isso, mas depois meu PATH se tornou essa bagunça longa de vários caminhos que era difícil de mudar sem cometer erros, então eu fui com a minha solução atual. Ocorre-me agora que eu poderia apenas alterar .bash_profile , dando a cada pacote uma linha separada (como acima) para facilitar o acesso, se esta for uma solução "melhor".

Eu também tenho uma pasta /Users/sajber/scripts para meus vários scripts Python, R e bash, que também são adicionados a PATH . Eu tenho um repositório Git neste diretório para controle de versão. É assim que você deve fazer as coisas?

Desculpe se essas perguntas são muito básicas! Eu realmente não sei qual é a maneira padrão de fazer as coisas em um ambiente Unix, sendo principalmente autodidata.

    
por erikfas 02.12.2015 / 09:47

3 respostas

2

Concordando que não há nada de errado em fazer dessa maneira, existem prós e contras. Eu achei útil manter uma distinção entre scripts que eu desenvolvo localmente e programas que eu obtenho de outros lugares:

  • scripts que desenvolvo localmente têm um histórico de alterações ao qual preciso fazer referência, enquanto
  • os programas que obtenho de outros lugares são mantidos por outros (com seu próprio histórico de alterações).

Como os "meus" scripts são mais convenientes para atualizar nos lugares onde são executados, então é útil (para mim, pelo menos) ter mais de um diretório bin.

Antes de me envolver na criação de pacotes para meus programas, usei /usr/local para o último, fazendo

./configure && make && sudo make install

e a maioria dos programas que usam scripts relacionados ao autoconf assumem como padrão este esquema.

Outros, claro, terão suas próprias preferências: faça o que funciona melhor para você.

    
por 02.12.2015 / 10:02
1

Não há nada de errado em fazer isso dessa maneira.

    
por 02.12.2015 / 09:56
1

Isso começou como um comentário, mas ficou muito longo e detalhado ...

Não há nada de errado em fazer isso para programas e scripts de uso pessoal (isto é, que só serão usados pelo seu id de usuário). Na verdade, o que você está fazendo é uma boa prática, embora você possa querer fazer um symlink dos binários em / Users / saberj / bin ao invés de copiá-los - assim será mais fácil acompanhar de onde cada binário veio (e mais fácil para excluí-los ou atualizá-los).

Os programas que devem ser usados por todos os usuários no sistema devem ser instalados como pacotes (se os pacotes estiverem disponíveis) ou instalados em / usr / local usando uma ferramenta como o GNU stow , que fornece alguns dos benefícios do empacotamento (incluindo a desinstalação fácil) para software não empacotado.

    
por 02.12.2015 / 11:05