Quais são as armadilhas de usar exclusivamente o PIP em um ambiente CONDA?
fundo
A documentação oficial e este blog no mesmo site - recomendo instalar o máximo de requisitos possível com oconda
uso do pip. Aparentemente, isso ocorre porque não conda
terá conhecimento de quaisquer alterações nas dependências feitas por pip
e, portanto, não será capaz de resolver as dependências corretamente.
Questão
Agora, se alguém usa exclusivamente pip
e não instala nada com conda
, parece razoável esperar conda
que não precise estar ciente de nenhuma mudança feita por pip
- pois conda
efetivamente se torna uma mera ferramenta para isolar dependências e gerenciar versões. No entanto, isso vai contra a recomendação oficial, pois NÃO instalará tantos requisitos quanto possívelconda
.
Portanto, a questão permanece: há alguma desvantagem conhecida de usar exclusivamentepip
em um conda
ambiente?
Tópicos semelhantes
Um tópico semelhante foi abordado um pouco aqui, mas não cobre o caso de uso exclusivo pip
em um conda
ambiente. Eu também estive aqui:
- Razões específicas para favorecer pip versus conda ao instalar pacotes Python
- Qual é a diferença entre pip e conda?
- Usando Pip para instalar pacotes no ambiente Anaconda
Respostas
Não tenho certeza se podemos dar uma resposta abrangente sobre isso, mas algumas das principais coisas que vêm à mente são:
Falta de suporte profundo para resolução de dependências não-Python . Embora mais rodas que agrupam recursos não-Python tenham se tornado disponíveis ao longo do tempo, não está nem perto da cobertura que Conda fornece por ser um gerente geral de pacotes em vez de específico do Python. Para quem faz computação interoperável (por exemplo,
reticulate
), espero que o Conda seja o preferido.Bibliotecas otimizadas . Mais ou menos relacionado ao primeiro ponto, mas a equipe do Anaconda fez um esforço para construir versões otimizadas de pacotes (por exemplo, MKL para
numpy
). Não tenho certeza se o equivalente está disponível através do PyPI. 1Redundância de desperdício entre ambientes . Conda usa hardlinking quando os pacotes e ambientes estão no mesmo volume e oferece suporte para softlinking entre volumes. Isso ajuda a minimizar a replicação de quaisquer pacotes instalados em vários ambientes.
A exportação complica . Ao exportar (
conda env export
), o Conda não pega todos ospip
pacotes instalados - apenas os que vêm do PyPI. Ou seja, ele sentirá falta de coisas instaladas do GitHub, etc. Se alguém seguir a rota apenas de pip, acho que uma estratégia de exportação mais confiável seria usarpip freeze > requirements.txt
e, em seguida, fazer um YAML comochannels: - defaults dependencies: - python=3.8 # specify the version - pip - pip: - -r requirements.txt
com o qual recriar o ambiente.
Dito isso, eu poderia facilmente imaginar que nada disso importa para algumas pessoas (a maioria delas são conveniências), especialmente aquelas que tendem a trabalhar puramente em Python. Em tais casos, entretanto, não vejo por que alguém simplesmente não abriria mão do Conda e usaria um gerenciador de ambiente virtual específico para Python.
[1] Alguém, por favor, me corrija se você souber o contrário.