Pacotes Python são freqüentemente hospedados em muitos repositórios de distribuição. Depois de ler este tutorial, especificamente a seção intitulada "Deseja realmente fazer isso", evitei usar o pip e preferi usar o repositório do sistema, apenas recorrendo ao pip quando preciso instalar um pacote que não esteja no repositório.

No entanto, como esse é um método de instalação inconsistente, seria melhor usar apenas o pip? Quais são os benefícios / detratores do uso do pip no próprio repositório do sistema para pacotes disponíveis nos dois locais?

O link que eu incluí indica

A vantagem de sempre usar pacotes Debian / NeuroDebian padrão, é que os pacotes são cuidadosamente testados para serem compatíveis entre si. Os pacotes Debian registram dependências com outras bibliotecas, para que você sempre obtenha as bibliotecas necessárias como parte da instalação.

Eu uso arco. Este é o caso de outros sistemas de gerenciamento de pacotes além do apt?

A maior desvantagem que vejo ao usar pippara instalar módulos Python em seu sistema, como módulos de sistema ou módulos de usuário, é que o sistema de gerenciamento de pacotes da sua distribuição não os conhecerá. Isso significa que eles não serão usados ​​para nenhum outro pacote que precise deles e que você poderá instalar no futuro (ou que possa começar a usar um desses módulos após uma atualização); você terminará com as versões pip- e gerenciadas pela distribuição dos módulos, o que pode causar problemas (eu encontrei outra instância disso recentemente). Portanto, sua pergunta acaba sendo uma proposta de tudo ou nada: se você usar apenaspip para módulos Python, você não pode mais usar o gerenciador de pacotes da sua distribuição para qualquer coisa que queira usar um módulo Python ...

O conselho geral dado na página à qual você se vinculou é muito bom: tente usar os pacotes da sua distribuição o máximo possível, use apenas pippara módulos que não estão empacotados e, quando o fizer, faça isso na configuração do usuário e não no sistema. Largo. Use ambientes virtuais o máximo possível, principalmente para o desenvolvimento de módulos. Especialmente no Arch, você não deve encontrar problemas causados ​​por módulos mais antigos; mesmo em distribuições onde isso pode ser um problema, os ambientes virtuais lidam com isso com bastante facilidade.

Sempre vale a pena considerar que os pacotes de biblioteca e módulo de uma distribuição são empacotados principalmente para o uso de outros pacotes na distribuição; tê-los por perto é um bom efeito colateral para o desenvolvimento usando essas bibliotecas e módulos, mas esse não é o caso de uso principal.

TL; DR

• use pip(+ virtualenv) para coisas (bibliotecas, estruturas, talvez ferramentas de desenvolvimento) que seus projetos (que você desenvolve) usam
• use o gerenciador de pacotes para os aplicativos que você usa (como usuário final)

Dependências de desenvolvimento

Se você estiver desenvolvendo software em Python, convém usar pippara todas as dependências do projeto, sejam elas dependências de tempo de execução, dependências em tempo de compilação ou outras coisas necessárias para testes e verificações de conformidade automáticas (linter, verificador de estilo, verificador de tipo estático) ...)

Há várias razões para isso:

• Isso permite que você use o virtualenv (diretamente ou por meio do virtualenvwrapper ou pipenv ou outros meios) para separar dependências de projetos diferentes e isolar os aplicativos python usados ​​"em produção" (como usuário) de quaisquer travessuras exóticas (ou até mesmo incompatibilidades) que podem continuar no desenvolvimento.
• Isso permite rastrear todas as dependências de um projeto em um arquivo requirements.txt(se o seu projeto for um aplicativo) ou setup.py(se o seu projeto for uma biblioteca ou estrutura). Isso pode ser verificado no controle de revisão (por exemplo, Git) junto com o código-fonte, para que você sempre saiba qual versão do seu código se baseou em quais versões de suas dependências.
• A descrição acima permite que outros desenvolvedores colaborem em seu projeto, mesmo que não usem a mesma distribuição Linux ou nem o mesmo sistema operacional (se as dependências usadas também estiverem disponíveis no Mac e Windows ou o que quer que elas usem).
• Você não deseja que atualizações automáticas do gerenciador de pacotes do seu sistema operacional quebre seu código. Você deve atualizar suas dependências, mas deve fazê-lo conscientemente e às vezes que escolher, para poder estar pronto para corrigir seu código ou reverter a atualização. (O que é fácil se você acompanhar a declaração de dependência completa no seu sistema de controle de revisões, juntamente com o seu código.)

Se você sentir que precisa separar dependências diretas e indiretas (ou distinguir entre o intervalo de versão aceitável para uma dependência e a versão real usada, consulte "version pinning"), procure nas ferramentas de pip e / ou pipenv. Isso também permitirá distinguir entre dependências de compilação e teste. (A distinção entre dependências de compilação e tempo de execução provavelmente pode ser codificada setup.py)

Aplicativos que você usa

Para coisas que você usa como aplicação normal e que só acontece a ser escrito em Python, preferem gerenciador de pacotes do seu sistema operacional. Ele garantirá que esteja razoavelmente atualizado e compatível com outras coisas instaladas pelo gerenciador de pacotes. A maioria das distribuições Linux também afirma que não distribui nenhum malware.

Se algo que você precisa não está disponível no repositório de pacotes padrão da sua distribuição, você pode conferir repositórios de pacotes adicionais (por exemplo, barra de lançamento de distribuições baseadas em deb) ou usá-lo de pipqualquer maneira. --userNesse último caso, use para instalar na casa do usuário em vez de em todo o sistema, para que você tenha menos probabilidade de interromper a instalação do Python. (Para coisas que você precisa apenas temporariamente ou raramente, você pode até usar um virtualenv.)

Outro motivo para acompanhar o gerenciador de pacotes é que as atualizações serão aplicadas automaticamente, o que é essencial para a segurança. Pense se o pacote de beans usado pelo Equifax foi atualizado automaticamente via yum-cron-security, o hack pode não ter acontecido.

Na minha caixa de desenvolvimento pessoal, eu uso Pip, em prod, uso pacotes.

Se estamos falando sobre a instalação de pacotes python para usar no código que você está escrevendo, use pip.

Para cada projeto em que você está trabalhando, crie um ambiente virtual e use apenas o pip para instalar as coisas que esse projeto precisa. Dessa forma, você instala todas as bibliotecas que você usa de maneira consistente, e elas estão contidas e não interferem em nada que você instala através do seu gerenciador de pacotes.

Se você planeja lançar qualquer código python, normalmente você adicionará um setup.pyou requirements.txtao seu projeto, o que permitirá ao pip obter automaticamente todas as suas dependências. Permitindo criar ou recriar facilmente um ambiente virtual para esse projeto.

Sumário

Existem três categorias gerais de módulos com as quais você está lidando:

1. Os programas de suporte instalados para todos os usuários com o sistema de pacotes do SO. (Isso pode até incluir ferramentas e bibliotecas usadas pelas pessoas que programam em Python; veja abaixo.) Para isso, você usa os pacotes do SO onde é possível e pipinstala nos diretórios do sistema quando necessário.
2. Os programas de suporte instalados por um usuário específico apenas para uso próprio e também para certos aspectos do uso "diário" do Python como linguagem de script. Para isso, ela usa pip --user, talvez pyenv ou pythonz , e ferramentas e táticas semelhantes.
3. Aqueles que dão suporte ao desenvolvimento e uso de um aplicativo específico. Para estes você usa virtualenv(ou uma ferramenta similar).

Cada nível aqui também pode estar recebendo suporte de um nível anterior. Por exemplo, nosso usuário em (2) pode confiar em um intérprete Python instalado via pacotes de SO.

Entrando nisso com mais detalhes:

Programas e pacotes do sistema

Os programas escritos em Python que você deseja "apenas executar" são fáceis: basta usar as ferramentas de instalação do SO e permitir que elas tragam o que precisam; isso não é diferente de um programa não-Python. É provável que isso traga ferramentas / bibliotecas Python (como o próprio interpretador Python!) Nas quais os usuários da sua máquina podem começar a confiar; isso não é um problema, desde que eles entendam a dependência e, idealmente, conheçam meios alternativos para lidar com isso em hosts que não fornecem essas dependências.

Um exemplo comum e simples dessa dependência são alguns dos meus scripts pessoais ~/.local/bin/que começam com #!/usr/bin/env python. Eles funcionarão bem (desde que executados no Python 2) no RH / CentOS 7 e na maioria das instalações (mas não todas) do Ubuntu; eles não estarão em uma instalação básica da Debian ou no Windows. Por mais que eu não goste de meu ambiente pessoal ter muitas dependências de pacotes de SO (eu trabalho em vários SOs diferentes), algo como isso acho bastante aceitável; meu plano de backup nos hosts raros que não têm um sistema Python e não conseguem um é usar um sistema de usuário, conforme descrito abaixo.

Pessoas que usam um interpretador python do sistema também geralmente dependem do sistema pip3. É aí que eu costumo traçar a linha nas dependências do meu sistema; tudo a partir de agora virtualenveu lido comigo mesmo. (Por exemplo, meu script de ativação padrão depende de qualquer coisa pip3ou pipesteja no caminho, mas baixa sua própria cópia virtualenvpara inicializar o ambiente virtual que está criando.

Dito isto, provavelmente há circunstâncias em que é perfeitamente razoável disponibilizar mais um ambiente de desenvolvimento. Você pode ter interfaces Python em pacotes complexos (como um DBMS) em que deseja usar a versão do sistema e acha melhor que também permita que o sistema escolha o código de biblioteca Python específico que você usará para conversar com ele. Ou você pode estar implantando muitos hosts com um ambiente de desenvolvimento básico para uma classe Python e acha mais fácil automatizar com pacotes de sistema padrão.

Programas e Pacotes "Diários do Usuário"

Os usuários podem ter bibliotecas ou programas Python que não se encaixam bem em um ambiente virtual porque, em primeiro lugar, desejam criar ambientes virtuais (por exemplo, virtualenvwrapper ) ou são coisas que você costuma usar na linha de comando, mesmo enquanto fazendo trabalho não-Python. Mesmo que eles tenham a capacidade de instalar versões do sistema, eles podem se sentir mais confortáveis ​​em instalar os seus próprios (por exemplo, porque desejam usar a versão mais recente da ferramenta e suas dependências).

Geralmente pip --useré o que as pessoas usarão para isso, embora certas dependências, como o próprio interpretador Python, exijam um pouco mais do que isso. pyenv e pythonz são úteis para criar intérpretes pessoais (instalados ~/.local/binpara serem o intérprete padrão ou não) e, é claro, sempre é possível criar "manualmente" a partir da fonte, se as bibliotecas dev estiverem disponíveis.

Eu tento manter o conjunto mínimo de coisas instaladas aqui: virtualenvwrapper (porque eu o uso constantemente) e talvez a versão mais recente do pip. Tento evitar dependências fora da biblioteca padrão ou no Python 3 para scripts pessoais que escrevo para serem usados ​​em muitos hosts. (Embora veremos quanto tempo eu posso aguentar isso enquanto passo mais e mais desses scripts pessoais para o Python.)

Ambientes separados de desenvolvimento de aplicativos e tempo de execução

Esta é a coisa virtualenv usual. Para o desenvolvimento, você quase sempre deve usar um virtualenv para garantir que não esteja usando dependências do sistema ou, geralmente, mais de um para testar em diferentes versões do Python.

Esses ambientes virtuais também são bons para aplicativos com muitas dependências nas quais você deseja evitar poluir o ambiente do usuário. Por exemplo, costumo configurar um virtualenv para rodar notebooks Jupyter e similares.