A maior desvantagem que vejo ao usar pippara instalar módulos Python em seu sistema, seja como módulos de sistema ou como módulos de usuário, é que o sistema de gerenciamento de pacotes da sua distribuição não saberá sobre eles. Isso significa que eles não serão usados ​​para nenhum outro pacote que precise deles e que você queira instalar no futuro (ou que possa começar a usar um desses módulos após uma atualização); você acabará com pipversões dos módulos - e gerenciadas por distribuição, o que pode causar problemas (encontrei outra instância disso recentemente). Então sua pergunta acaba sendo uma proposta de tudo ou nada: se você usar apenaspippara 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 que você 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 tanto quanto possível, em particular para o desenvolvimento de módulos. Especialmente no Arch, você não deve se deparar com 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 (libs, frameworks, talvez dev tools) que seus projetos (que você desenvolve) usam
• use o gerenciador de pacotes para aplicativos que você usa (como usuário final)

Dependências de desenvolvimento

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

Há várias razões para isso:

• Isso permite que você use virtualenv (diretamente ou por meio de virtualenvwrapper ou pipenv ou outros meios) para separar dependências de projetos diferentes entre si e isolar os aplicativos python que você usa "em produção" (como usuário) de quaisquer travessuras exóticas (ou até mesmo incompatibilidades) que podem continuar em desenvolvimento.
• Isso permite rastrear todas as dependências de um projeto em um arquivo requirements.txt(se seu projeto for um aplicativo) ou setup.py(se 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 dependia de quais versões de suas dependências.
• O acima permite que outros desenvolvedores colaborem em seu projeto, mesmo que eles não usem a mesma distribuição Linux ou nem mesmo o mesmo sistema operacional (se as dependências usadas também estiverem disponíveis no Mac e Windows ou no que quer que eles usem)
• Você não quer que as atualizações automáticas do gerenciador de pacotes do seu sistema operacional quebrem seu código. Você deve atualizar suas dependências, mas deve fazê-lo conscientemente e nos horários que desejar, para 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 em seu sistema de controle de revisão, junto com 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, cf. "fixação de versão"), procure pip-tools e/ou pipenv. Isso também permitirá distinguir entre dependências de compilação e de teste. (A distinção entre dependências de compilação e tempo de execução provavelmente pode ser codificada em setup.py)

Aplicativos que você usa

Para coisas que você usa como aplicativo normal e que por acaso são escritas em Python, prefira o gerenciador de pacotes do seu sistema operacional. Ele garantirá que ele permaneça 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 verificar repositórios de pacotes adicionais (por exemplo, launchpad de distribuições baseadas em deb) ou usar de pipqualquer maneira. Se for o último, use --userpara instalar na casa do usuário em vez de em todo o sistema, para que seja menos provável que você interrompa a instalação do Python. (Para coisas que você precisa apenas temporariamente ou raramente, você pode até usar um virtualenv.)

Outra razão para usar o gerenciador de pacotes é que as atualizações serão aplicadas automaticamente, o que é crítico para a segurança. Pense se o pacote de beans usado pelo Equifax tivesse sido atualizado automaticamente via yum-cron-security, o hack pode não ter acontecido.

Na minha caixa de desenvolvimento pessoal eu uso Pip, em prod eu 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 usa de maneira consistente, e elas estão contidas e não interferem em nada que você instala por meio do 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á que o pip obtenha automaticamente todas as suas dependências. Permitindo que você crie ou recrie facilmente um ambiente virtual para esse projeto.

Resumo

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

1. Aqueles programas de suporte instalados para todos os usuários com o sistema de pacotes do sistema operacional. (Isso pode até incluir ferramentas e bibliotecas usadas por pessoas que programam em Python; veja abaixo.) Para isso, você usa os pacotes do sistema operacional onde puder e pipinstala nos diretórios do sistema quando necessário.
2. Aqueles programas de suporte instalados por um usuário específico apenas para seu próprio uso e também para certos aspectos de seu uso "dia a dia" 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 suportam o 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 estar contando com um interpretador Python instalado por meio de pacotes do SO.

Entrando nisso com um pouco mais de detalhes:

Programas e pacotes do sistema

Programas escritos em Python que você deseja "apenas executar" são fáceis: basta usar as ferramentas de instalação do sistema operacional e deixá-los trazer o que precisarem; isso não é diferente de um programa não-Python. Isso provavelmente trará ferramentas/bibliotecas Python (como o próprio interpretador Python!) nas quais os usuários em 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 de lidar com isso em hosts que não fornecem essas dependências.

Um exemplo comum e simples de tal 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 sejam executados no Python 2) no RH/CentOS 7 e na maioria (mas não em todos) as instalações do Ubuntu; eles não estarão sob uma instalação básica do Debian ou no Windows. Por mais que eu não goste que meu ambiente pessoal tenha muitas dependências em pacotes de SO (eu trabalho em vários SOs diferentes), algo assim eu acho bastante aceitável; meu plano de backup nos raros hosts que não possuem um sistema Python e não podem obter um é usar um sistema de usuário, conforme descrito abaixo.

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

Dito isso, 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) nos quais deseja usar a versão do sistema e achar que é melhor também deixar o sistema escolher 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 achar mais fácil automatizar com pacotes de sistema padrão.

Programas e pacotes "do dia-a-dia" do usuário

Os usuários podem ter bibliotecas ou programas Python que não se encaixam bem em um ambiente virtual porque desejam ajudar a criar ambientes virtuais em primeiro lugar (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 as versões do sistema, eles podem se sentir mais confortáveis ​​instalando as suas próprias (por exemplo, porque eles querem 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 construir interpretadores pessoais (instalados ~/.local/binpara ser o interpretador padrão ou não), e é claro que sempre se pode construir "à mão" 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. Eu 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 posso aguentar com isso à medida que movo mais e mais desses scripts pessoais para o Python.)

Desenvolvimento de aplicativos e ambientes de tempo de execução separados

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

Esses ambientes virtuais também são bons para aplicativos com muitas dependências em que você deseja evitar a poluição do ambiente do usuário. Por exemplo, eu costumo configurar um virtualenv para executar notebooks Jupyter e similares.