Was sind die Gefahren einer ausschließlichen Verwendung von PIP in einer CONDA-Umgebung?

Dec 02 2020

Hintergrund

Die offizielle Dokumentation und dieser Blog auf derselben Website - empfehlen, so viele Anforderungen wie möglich mitconda pip zu installieren . Dies liegt anscheinend daran, condadass Änderungen an den von vorgenommenen Abhängigkeiten pipnicht bekannt sind und daher Abhängigkeiten nicht korrekt aufgelöst werden können.

Frage

Wenn man nun ausschließlich etwas verwendet pipund darauf verzichtet, etwas zu installieren conda, ist es vernünftig zu erwarten conda, dass man sich keiner Änderungen bewusst sein muss, die von pip- so condaeffektiv wie ein bloßes Werkzeug zum Isolieren von Abhängigkeiten und Verwalten von Versionen - durchgeführt werden müssen. Dies widerspricht jedoch der offiziellen Empfehlung, da NICHT so viele Anforderungen wie möglich mit installiert werdenconda .

Es bleibt also die Frage: Gibt es einen bekannten Nachteil bei der ausschließlichen Verwendung pipin einer condaUmgebung?

Ähnliche Themen

Ein ähnliches Thema in waren berührt in einem wenig hier aber gilt nicht für den Fall ausschließlich unter Verwendung pipin einer condaUmgebung. Ich war auch hier:

  • Spezifische Gründe für die Bevorzugung von pip gegenüber conda bei der Installation von Python-Paketen
  • Was ist der Unterschied zwischen Pip und Conda?
  • Verwenden von Pip zum Installieren von Paketen in Anaconda Environment

Antworten

2 merv Dec 02 2020 at 03:49

Ich bin mir nicht sicher, ob man eine umfassende Antwort darauf geben kann, aber einige der wichtigsten Dinge, die mir in den Sinn kommen, sind:

  1. Fehlende Unterstützung für die Auflösung von Nicht-Python-Abhängigkeiten . Zwar sind im Laufe der Zeit mehr Räder verfügbar geworden, die Nicht-Python-Ressourcen bündeln, doch Conda bietet bei weitem keine Abdeckung, da es sich eher um einen allgemeinen Paketmanager als um Python-spezifische handelt. Für jeden, der interoperables Computing betreibt (z. B. reticulate), würde ich erwarten, dass Conda bevorzugt wird.

  2. Optimierte Bibliotheken . Das hängt irgendwie mit dem ersten Punkt zusammen, aber das Anaconda-Team hat sich bemüht, optimierte Versionen von Paketen (z. B. MKL für numpy) zu erstellen . Ich bin mir nicht sicher, ob das Äquivalent über PyPI verfügbar ist. 1

  3. Verschwenderische Redundanz in verschiedenen Umgebungen . Conda verwendet Hardlinking, wenn sich Pakete und Umgebungen auf demselben Volume befinden, und unterstützt Softlinking für das Übergreifen von Volumes. Dies hilft, die Replikation von Paketen zu minimieren, die in mehreren Umgebungen installiert sind.

  4. Erschwert den Export . Beim Exportieren von ( conda env export) nimmt Conda nicht alle pipinstallierten Pakete auf - nur die, die von PyPI stammen. Das heißt, es werden Dinge fehlen, die von GitHub usw. installiert wurden. Wenn man den Nur-Pip-Weg gehen würde, wäre es meiner Meinung nach eine zuverlässigere Exportstrategie pip freeze > requirements.txt, eine YAML-ähnliche zu verwenden

    channels:
      - defaults
    dependencies:
      - python=3.8  # specify the version
      - pip
      - pip:
        - -r requirements.txt
    

    mit denen die Umgebung neu zu erstellen.

Trotzdem konnte ich mir leicht vorstellen, dass für einige Leute nichts davon von Bedeutung ist (die meisten davon sind Annehmlichkeiten), insbesondere für diejenigen, die dazu neigen, nur in Python zu arbeiten. In solchen Fällen verstehe ich jedoch nicht, warum man nicht einfach ganz auf Conda verzichten und einen Python-spezifischen Manager für virtuelle Umgebungen verwenden würde.


[1] Jemand korrigiert mich bitte, wenn Sie etwas anderes wissen.