Was sind die Gefahren einer ausschließlichen Verwendung von PIP in einer CONDA-Umgebung?
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, conda
dass Änderungen an den von vorgenommenen Abhängigkeiten pip
nicht bekannt sind und daher Abhängigkeiten nicht korrekt aufgelöst werden können.
Frage
Wenn man nun ausschließlich etwas verwendet pip
und 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 conda
effektiv 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 pip
in einer conda
Umgebung?
Ähnliche Themen
Ein ähnliches Thema in waren berührt in einem wenig hier aber gilt nicht für den Fall ausschließlich unter Verwendung pip
in einer conda
Umgebung. 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
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:
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.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. 1Verschwenderische 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.
Erschwert den Export . Beim Exportieren von (
conda env export
) nimmt Conda nicht allepip
installierten 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 Exportstrategiepip freeze > requirements.txt
, eine YAML-ähnliche zu verwendenchannels: - 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.