Quels sont les pièges de l'utilisation exclusive de PIP dans un environnement CONDA?
Contexte
La documentation officielle et ce blog sur le même site Web - recommandez d' installer autant d'exigences que possible avecconda
puis utilisez pip. Apparemment, c'est parce que vous conda
ne serez pas au courant des modifications apportées aux dépendances pip
et ne sera donc pas en mesure de résoudre correctement les dépendances.
Question
Maintenant, si l'on utilise exclusivement pip
et va sans rien installer avec conda
, il semble raisonnable de s'attendre à conda
ne pas avoir besoin d'être au courant des modifications apportées par pip
- car conda
devient effectivement un simple outil pour isoler les dépendances et gérer les versions. Cependant, cela va à l'encontre de la recommandation officielle car on n'installeraconda
PAS autant d'exigences que possible avec .
La question demeure donc: y a-t-il un inconvénient connu à utiliser exclusivementpip
dans un conda
environnement?
Sujets similaires
Un sujet similaire dans a été un peu abordé ici mais ne couvre pas le cas de l'utilisation exclusive pip
dans un conda
environnement. J'ai aussi été ici:
- Raisons spécifiques pour favoriser pip par rapport à conda lors de l'installation de packages Python
- Quelle est la différence entre pip et conda?
- Utilisation de Pip pour installer des packages dans l'environnement Anaconda
Réponses
Je ne suis pas sûr de pouvoir donner une réponse complète à ce sujet, mais certaines des principales choses qui me viennent à l'esprit sont:
Manque de prise en charge approfondie de la résolution des dépendances non Python . Alors que de plus en plus de roues regroupant des ressources non Python sont devenues disponibles au fil du temps, la couverture que Conda fournit en étant un gestionnaire de packages général plutôt que spécifique à Python est loin d'être proche. Pour tous ceux qui font de l'informatique interopérable (par exemple
reticulate
), je m'attendrais à ce que Conda soit favorisé.Bibliothèques optimisées . En quelque sorte lié au premier point, mais l'équipe Anaconda a fait un effort pour créer des versions optimisées des packages (par exemple, MKL pour
numpy
). Je ne sais pas si l'équivalent est disponible via PyPI. 1Redondance inutile entre les environnements . Conda utilise la liaison fixe lorsque les packages et les environnements sont sur le même volume, et prend en charge la liaison douce pour s'étendre sur plusieurs volumes. Cela permet de minimiser la réplication des packages installés dans plusieurs environnements.
Complique l'exportation . Lors de l'exportation (
conda env export
), Conda ne récupère pas tous lespip
packages installés - uniquement ceux qui proviennent de PyPI. Autrement dit, il manquera des éléments installés à partir de GitHub, etc. Si l'on empruntait la voie pip uniquement, je pense qu'une stratégie d'exportation plus fiable serait d'utiliserpip freeze > requirements.txt
, puis de créer un YAML commechannels: - defaults dependencies: - python=3.8 # specify the version - pip - pip: - -r requirements.txt
avec lequel recréer l'environnement.
Cela dit, je pourrais facilement imaginer que rien de tout cela n'a d'importance pour certaines personnes (la plupart d'entre elles sont des commodités), en particulier celles qui ont tendance à travailler uniquement en Python. Dans de tels cas, cependant, je ne vois pas pourquoi on ne renoncerait pas simplement à Conda et utiliserait un gestionnaire d'environnement virtuel spécifique à Python.
[1] Quelqu'un, s'il vous plaît, corrigez-moi si vous savez le contraire.