Ich weiß, dass pip ein Paketmanager für Python-Pakete ist. Allerdings habe ich gesehen, dass die Installation auf der Website von IPython conda verwendet, um IPython zu installieren.
Kann ich pip verwenden, um IPython zu installieren? Warum sollte ich conda als einen weiteren Python-Paketmanager verwenden, wenn ich bereits pip habe?
Was ist der Unterschied zwischen pip und conda?
Kann ich pip verwenden, um iPython zu installieren?
Sicher, sowohl (erster Ansatz auf der Seite)
pip install ipythonund (dritter Ansatz, der zweite ist conda)
Sie können IPython manuell von GitHub oder PyPI herunterladen. Um eine dieser Versionen zu installieren, entpacken Sie diese und führen Sie folgendes im obersten Quellverzeichnis mit dem Terminal aus:
pip install .
werden als offiziell empfohlene Möglichkeiten zur Installation angegeben.
Warum soll ich conda als weiteren Python-Paketmanager verwenden, wenn ich bereits pip habe?
Wie hier gesagt:
Wenn Sie ein spezifisches Paket benötigen, vielleicht nur für ein Projekt, oder wenn Sie das Projekt mit jemand anderem teilen müssen, scheint conda angemessener zu sein.
Conda übertrifft pip in (YMMV)
Was ist der Unterschied zwischen pip und conda?
Das wird umfassend von anderen beantwortet.
Während die anderen Antworten auf die Ziele und Vorteile von pip/conda hinweisen, könnte es auch interessant sein, ihre Probleme aus einer Verpackungsperspektive zu erwähnen.
Das Hauptproblem bei pip ist, dass gemeinsame C-Erweiterungsbibliotheken nicht zwischen mehreren Paketen geteilt werden. Das bedeutet, dass Bindungspakete ihren gesamten Erweiterungsabhängigkeitsbaum erstellen und bündeln müssen, was nicht elegant ist. Es verbraucht mehr Festplattenspeicher als notwendig, und Sicherheitsupdates für Basiseinrichtungen können nicht auf oberster Ebene verwaltet werden, sondern müssen für jedes Erweiterungspaket separat bewertet werden.
Conda hingegen arbeitet auf der Sysroot-Ebene und kann Bibliotheken über Sprachgrenzen hinweg teilen. Auch wenn dies eine großartige Idee ist, hat die Conda-Verpackung in der Praxis viele Probleme. Meiner Meinung nach liegt dies nicht an einem Fehler im Prinzip, sondern an der Umsetzung von Conda.
Conda folgt einem Verpackungsmodell, bei dem nicht die eigentlichen Projektautoren im Hauptkanal veröffentlichen, sondern die Verpackung wird mit Hilfe von "Rezept-Futterstoffen" durch einen Drittanbieter durchgeführt. Das bedeutet, Updates müssen manuell durchgeführt werden, und neuere oder weniger beliebte Pakete sind oft nicht verfügbar. Viele Pakete werden nicht regelmäßig aktualisiert, sodass Builds fehlen können und die aktuelle Version veraltet ist. Darüber hinaus kann die Verpackung durch Dritte in einigen Fällen zu einer Verschlechterung der Qualität führen (z. B. ABI-Sicherheitsprobleme). Es sind die Originalautoren, die am besten wissen, wie sie ihr Paket ordnungsgemäß erstellen/konfigurieren sollen, nicht Dritte.
Conda verursacht auch viel Verpackungsduplizierung aufgrund von Inkompatibilität mit PyPA-Stil-Paketen. Dies scheint grundsätzlich unnötig zu sein - warum könnte Conda nicht einfach eine Kompatibilitätsschicht bereitstellen, die es ermöglicht, eine Abhängigkeit von einem PyPA-Paket anzugeben? Alle Metadaten wären vorhanden, nur mit unterschiedlichen Konventionen. Die Realität ist jedoch, dass Conda das nicht tut, und es gab lange Zeit keine wirklichen Bestrebungen, dies zu ändern. Das könnte jedoch den Wartungsaufwand für reine Python-Pakete erheblich reduzieren und für bestimmte Erweiterungsprojekte hilfreich sein, die sehr aufwändig zu Conda-Verpackungen wären.
Die Unterstützung für direkte Verpackungen von Upstream-Projekten ist im Allgemeinen schlecht. Es ist in gewissem Maße mit benutzerdefinierten Kanälen möglich, aber schlecht, da Endbenutzer die einzelnen Kanäle bestimmen und den gesamten Kanalbaum manuell aktivieren müssen. Darüber hinaus scheinen die Build-Tools langsam und unflexibel zu sein, da sie sehr auf den Fall der Futterstoffe und native Hosts ausgerichtet sind.
Ein weiterer Nachteil von Conda ist, dass sein Konzept der Umgebungen das "Abhängigkeits-Höllen"-Problem nicht wirklich lösen kann. Es ermöglicht nicht, Konflikte zu beheben, indem mehrere Versionen eines Pakets parallel in derselben Umgebung installiert werden.
Virtuelle Umgebungen sind ein längst bekanntes Konzept und ebenfalls in der PyPA-Welt verfügbar. Heutzutage bietet pip auch einen vollständigen Abhängigkeitsauflöser.
pip ist nur für Python
conda ist nur für Anaconda + andere wissenschaftliche Pakete wie R-Abhängigkeiten usw. NICHT jeder benötigt Anaconda, das bereits mit Python geliefert wird. Anaconda ist hauptsächlich für diejenigen, die maschinelles Lernen/tiefes Lernen usw. betreiben. Ein gelegentlicher Python-Entwickler wird Anaconda nicht auf seinem Laptop ausführen.
Ich habe möglicherweise einen weiteren Unterschied von geringer Bedeutung festgestellt. Ich habe meine Python-Umgebungen unter /usr statt unter /home oder ähnlichem. Um dorthin zu installieren, müsste ich sudo install pip verwenden. Für mich war die unerwünschte Nebenwirkung von sudo install pip etwas anders als anderswo weit verbreitet berichtet wird: Nachdem ich dies getan hatte, musste ich python mit sudo ausführen, um eines der mit sudo installierten Pakete importieren zu können. Ich gab das auf und fand schließlich heraus, dass ich sudo conda verwenden konnte, um Pakete in einer Umgebung unter /usr zu installieren, die dann normal importiert wurden, ohne dass sudo Berechtigung für python erforderlich war. Ich habe sogar sudo conda verwendet, um ein defektes pip zu reparieren, anstatt sudo pip uninstall pip oder sudo pip --upgrade install pip zu verwenden.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
