Quels sont les pièges de l'utilisation exclusive de PIP dans un environnement CONDA?

Dec 02 2020

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 condane serez pas au courant des modifications apportées aux dépendances pipet ne sera donc pas en mesure de résoudre correctement les dépendances.

Question

Maintenant, si l'on utilise exclusivement pipet va sans rien installer avec conda, il semble raisonnable de s'attendre à condane pas avoir besoin d'être au courant des modifications apportées par pip- car condadevient 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 condaenvironnement?

Sujets similaires

Un sujet similaire dans a été un peu abordé ici mais ne couvre pas le cas de l'utilisation exclusive pipdans un condaenvironnement. 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

2 merv Dec 02 2020 at 03:49

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:

  1. 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é.

  2. 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. 1

  3. Redondance 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.

  4. Complique l'exportation . Lors de l'exportation ( conda env export), Conda ne récupère pas tous les pippackages 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'utiliser pip freeze > requirements.txt, puis de créer un YAML comme

    channels:
      - 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.