Anaconda、Miniconda、Conda、pip的相互關系。如果你想要跳過這篇文章，并得到討論的要點，你可以閱讀每個標題以及下面的摘要。

認為#1：Conda是一個發行版，不是一個軟件包管理器

現實：Conda是一個包管理器;Anaconda是一個發行包。雖然Conda與Anaconda一起包裝，但兩者是具有不同目標的不同實體。

軟件發布包是預先構建和預配置的包的集合，其可以在系統上安裝和使用。包管理器是自動化安裝，更新和刪除包的過程的工具。

Conda，其“conda install”，“conda update”和“conda

remove”子命令，完全屬于第二個定義：它是一個包管理器。

也許這里的混亂來自于Conda緊密耦合到兩個軟件分發：Anaconda和Miniconda的事實。

Anaconda軟件在PyData生態系統中的完整分布，包括Python本身以及幾百個第三方開源項目的二進制文件。

Miniconda本質上是一個conda環境的安裝程序，只包含Conda及其依賴項，以便您可以從頭開始安裝所需的。

但不要弄錯誤：Conda與Anaconda / Miniconda不同，Python本身(如果你愿意)可以自行安裝。

認為#2：Conda是一個Python包管理器

現實：Conda是一種通用包管理系統，旨在構建和管理任何語言的任何類型的軟件。因此，它也適用于Python包。

因為conda來自于Python(更具體地說是PyData)社區，許多人錯誤地認為它基本上是一個Python包管理器。情況并非如此：conda旨在管理任何軟件堆棧中的包和依賴關系。在這個意義上，它不像pip，更像是apt或yum等跨平臺版本。

如果你使用conda，你已經可以利用許多非Python包;以下命令將列出您環境中的那些：

$ conda search –canonical | grep -v ‘py\d\d’

在我的系統上，有350個結果：這些是我的Conda /

Python環境中的包，這些包基本上是由Python-only工具(如pip和virtualenv)無法管理的。

認為#3：Conda和pip是直接競爭對手

現實：Conda和pip服務于不同的目的，并且只在一小部分任務中直接競爭：即在孤立的環境中安裝Python包。

Pip代表Pip Installs

Packages，是Python的官方認可的包管理器，最常用于安裝在Python包索引(PyPI)上發布的包。

pip和PyPI都由Python包裝管理局(PyPA)管理和支持。

簡而言之，pip是Python包的通用管理器;

conda是一個與語言無關的跨平臺環境管理器。對于用戶，最顯著的區別可能是這樣的：pip在任何環境中安裝python包;

conda安裝在conda環境中的任何包裝。如果你正在做的是在孤立的環境中安裝Python包，conda和pip +

virtualenv大多是可互換的，模數依賴處理和包可用性的一些差異。通過隔離環境(conda-env或virtualenv)，您可以在其中安裝軟件包，而無需修改您的系統Python安裝。

即使放棄認為#2，如果我們專注于只是安裝Python包，conda和pip服務不同的受眾和不同的目的。

如果你想在現有的系統Python安裝中管理Python包，conda不能幫助你：通過設計，它只能在conda環境中安裝包。

如果你想說，使用依賴于外部依賴的許多Python包(NumPy，SciPy和Matplotlib是常見的例子)，同時以一種有意義的方式跟蹤這些依賴，pip不能幫助你：它

管理Python包和只有Python包。

Conda和pip不是競爭對手，而是側重于不同用戶組和使用模式的工具。

認為#4：在第一個地方創造conda是不負責任和分裂

現實：Conda的創作者將Python的標準包裝推向了極限十多年，并且只有在明確了它是唯一合理的前進道路時才創造了第二個工具。

根據Python的哲學，在Python做任何事情“應該有一個，最好只有一個明顯的方式來做”。那么為什么conda的創建者會通過引入一種新的方式來安裝Python包呢?為什么他們沒有貢獻回Python社區并改進pip來克服它的缺陷?

事實證明，這正是他們所做的。在2012年之前，PyData /

SciPy生態系統的開發人員很大程度上在Python社區開發的包管理解決方案的約束下工作。早在2001年，NumPy項目就試圖使它處理NumPy分布的復雜要求。他們將大部分的NETLIB綁定到一個單一的Python包(你可能知道這是SciPy)，實際上創建一個分發為python包，以規避Python的分發工具不能用任何有意義的方式管理這些額外的Python依賴。為了閱讀一些關于這些痛點的細節以及如何導致Conda，我建議Travis

Oliphant的2013年博客文章。

但是為什么Conda的創作者不和Python包裝人員談談，一起找出這些挑戰呢?事實證明，他們談了。

Conda的創始來自Guido van

Rossum先生在2012年首屆PyData聚會上發表演講;在一個關于包裝困難的問題上，他告訴我們，當談到包裝，“真的聽起來像你的需求是相當大的Python社區，你只是更好地建立自己的”的討論)。即使在遵循這個來自BDFL的建議的情況下，PyData社區繼續與核心Python開發人員的對話和協作的主題：另一個公開的例子是CPython核心開發人員Nick

Coghlan邀請在SciPy 2014主題演講(見視頻here

)。他做了一個很好的演講，在軟件分發的“未解決問題”的背景下具體討論了pip和conda，并提到了具有適合特定用戶需求的多種分發方式的價值。

Conda不是分裂的，Nick和其他人在Python包裝管理局正式認可conda作為Python代碼的許多重要的重新分發器之一，并且正在努力更好地使這些工具與Python包索引無縫地工作。

認為#5：conda不能使用virtualenv，所以它對我的工作流沒有用

現實：你實際上可以在一個virtualenv中安裝(一些)conda包，但更好的是使用Conda自己的環境管理器：它與pip完全兼容，并且比virtualenv有幾個優點。

virtualenv / venv是允許用戶創建與pip一起使用的隔離的Python環境的實用程序。

Conda有自己的內置環境管理器，可以與conda和pip無縫工作，并且事實上比virtualenv / venv有幾個優點：

conda環境集成了不同Python版本的管理，包括Python本身的安裝和更新。

Virtualenvs必須在現有的，外部管理的Python可執行文件上創建。

conda環境可以跟蹤非python依賴;例如無縫管理依賴性和基本工具(如LAPACK或OpenSSL)的并行版本

而不是構建在符號鏈接上的環境 - 這破壞了virtualenv的隔離，并且對于非Python依賴關系有時可能是脆弱的 -

conda-envs是單個可執行路徑中的真正隔離環境。

雖然virtualenvs與conda軟件包不兼容，但conda環境與pip軟件包完全兼容。第一個conda安裝pip，然后你可以pip安裝任何可用的包在那個環境中。您甚至可以在conda環境文件中顯式地列出pip包，這意味著完整的軟件堆棧可以從單個環境元數據文件完全重現。

也就是說，如果你想在你的virtualenv中使用conda，它是可能的：

$ virtualenv test_conda

$ source test conda/bin/activate

$ pip install conda

$ conda install numpy

這將在您的virtualenv中安裝conda的MKL啟用的NumPy包。

我不會推薦這個：我找不到這個功能的文檔，并且結果似乎相當脆弱 -

例如，試圖conda更新python內的virtualenv失敗在一個非常不起眼和不可恢復的方式，看起來與

符合連接virtualenv的架構。

這似乎不是conda和virtualenv之間的一些根本不兼容，而是與構建過程中的一些細微不一致有關，因此是潛在可固定的(例如，參見conda

Issue 1367和anaconda Issue 498)。

如果你想避免這些困難，一個更好的想法是pip安裝conda，然后創建一個新的conda環境中安裝conda包。

對于習慣于使用pip / virtualenv / venv命令語法的人來說，conda文檔包括conda和pip /

virtualenv命令之間的轉換表。

認為#6：現在pip使用wheels，conda不再需要

現實：wheels只是提出conda發展的許多挑戰之一，而wheels有弱點，Conda的二進制文件解決。

驅動Conda創建的一個困難是，pip可以只分發源代碼，而不是預編譯的二進制分發，這對于構建諸如NumPy和SciPy的擴展重模塊的用戶來說尤其具有挑戰性。

Conda以自己的方式解決了這個問題后，pip本身增加了對輪子的支持，這是一個二進制格式，旨在解決pip中的這個難題。有了這個問題在共同的工具，解決Conda早期采納者現在應該回到pip?

不必要。跨平臺二進制文件的分發只是conda中解決的許多問題之一。編譯的二進制文件聚焦了conda的另一個重要部分：有意義地跟蹤非Python依賴關系的能力。因為pip的依賴關系跟蹤只限于Python包，所以在輪子中這樣做的主要方法是將發布的依賴包版本與Python包二進制包捆綁在一起，這使得更新這樣的依賴很痛苦(最近OpenSSL的安全更新)。此外，conda包括一個真正的依賴解析器，一個pip目前缺乏的組件。

對于科學用戶，conda還允許將構建鏈接到優化的線性代數庫，Continuum使用其自由提供的MKL啟用的NumPy /

SciPy。

Conda甚至可以分發非Python構建需求，例如gcc，這大大簡化了在其分發的預編譯二進制代碼上構建其他包的過程。如果你試圖使用pip的輪子，你最好希望你的系統有編譯器和設置兼容那些用來最初構建的問題的車輪。

認為#7：conda不開源;它被綁定到一個營利公司，可以開始收取服務，只要他們想要

現實：conda(包管理器和構建系統)是100%開源，Anaconda(發行版)也幾乎在那里。

在開放源代碼世界中，有一些對營利性實體的根本不信任，而Anaconda是由Continuum

Analytics創建的，而且是大型企業產品的一個免費組件，這使得一些人擔心。

讓我們拋開一個事實，Continuum是，在我看來，是少數幾家公司真正做開放軟件正確的方式(一個話題另一個時間)。忽略這一點，事實是，Conda本身

- 包管理器，提供以跨平臺方式構建，分發，安裝，更新和管理軟件的實用程序 -

是100%開源，可在GitHub和BSD許可。即使對于Anaconda(發行版)，EULA只是一個標準的BSD許可證，用于創建Anaconda的工具鏈也是100%開源。總之，當使用Conda時，沒有必要擔心知識產權問題。

如果Anaconda /

Miniconda發行版仍然擔心，放心：你不需要安裝Anaconda或Miniconda來獲得conda，雖然這些是方便的使用途徑。正如我們上面所看到的，你可以“pip

install conda”通過PyPI安裝它，而無需Continuum的網站。

認為#8：但Conda包本身是封閉的，對不對?

現實：雖然conda的默認渠道尚未完全開放，有一個由社區主導的努力(Conda-Forge)使conda包裝和分銷完全開放。

從歷史上看，默認conda通道的軟件包構建過程沒有盡可能開放，并且獲取構建更新的過程主要依賴于在Continuum上知道某人。謠言是，這主要是因為原始的conda包創建過程沒有像今天一樣明確和精簡。

但這正在改變。

Continuum正在努力打開他們的包裝食譜，并且我被告知，500多個包裝中只有幾十個仍然需要移植。這些少數食譜是Anaconda分布中唯一不完全開放的剩余部分。

如果這還不夠，那么在2016年初推出的一個新的以社區為主導的項目，而不是Continuum附屬項目，名為conda-forge，包含用于為任何軟件包創建社區驅動的構建的工具。軟件包通過github保持開放狀態，二進制文件使用免費CI工具自動構建，如TravisCI

for Mac OSX構建，AppVeyor for Windows構建和CircleCI for

Linux構建。每個包的所有元數據都位于Github存儲庫中，并且通過合并Github

pull請求(這是conda-forge中包更新的示例)完成包更新。

Conda-forge完全是社區為基礎的，由社區主導，雖然conda-forge可能還不夠成熟，無法完全替代默認的conda渠道，Continuum的創始人已經公開表示，這是他們會支持的方向。你可以在Wes

McKinney的最近的博客文章，conda-forge和PyData的CentOS時期更多地了解conda-forge的承諾。

認為#9：好的，但如果Continuum Analytics不折騰了，conda不會再工作了嗎?

現實：沒有，Conda本質上，Continuum

Analytics公司通過提供免費托管構建工件為社區服務。所有軟件分發都需要由某人，甚至PyPI托管。

的確，即使是conda-forge也將其軟件包發布到http://anaconda.org/，這是一個由Continuum

Analytics擁有和維護的網站。但在Conda沒有什么需要這個網站。事實上，conda中的自定義渠道的創建是有詳細記錄的，沒有什么可阻止某人建立和托管自己的私人分布使用Conda作為包管理器(conda索引是相關的命令)。考慮到conda食譜的開放性和構建系統conda-forge，如果你有理由這樣做不會很難反映你自己的服務器上的所有conda-forge。

如果你仍然擔心Continuum Analytics - 一個營利公司 -

通過托管conda包為社區服務，你應該也同樣擔心Rackspace - 一個盈利的公司 -

通過托管Python包索引服務社區。在這兩種情況下，一個營利性公司都是社區包裹管理系統目前表現形式的一部分。但在任何情況下，該公司的滅亡都會威脅到構建和分發系統的底層架構，這是完全自由和開源的。如果Rackspace或Continuum消失，社區只需為其依賴的開放式分配找到另一個主機和/或財務贊助者。

認為#10：每個人都應該放棄(conda | pip)和使用(pip | conda)!

現實：pip和conda服務于不同的需求，我們應該更少關注他們如何競爭，更多地關注他們如何一起工作。

正如在神話#2中提到的，Conda和pip是不同的項目，不同的目標讀者：pip在任何環境中安裝python包;

conda安裝在conda環境中的任何包裝。考慮到在Python的禪意中提出的崇高理想，人們可能希望pip和conda可以以某種方式組合，所以將有一個而且只有一個明顯的方式安裝包。

但這永遠不會發生。這兩個項目的目標太不同了。除非pip項目被廣泛地重新定義，否則它永遠不能有意義地安裝和跟蹤conda所做的所有非Python包：該架構是Python特定的(正確)以Python為重點。

Pip與PyPI一起旨在成為一個靈活的出版物和分發平臺以及Python軟件包的管理器，并且它的表現非常出色。

同樣，除非conda包被廣泛重新定義，它將永遠不會取代pip /

PyPI作為Python代碼的一般發布和分發平臺。在其核心，conda關注在多個平臺上健壯地運行復雜的多語言軟件棧所需的詳細依賴關系跟蹤類型。

conda的存儲庫中的每個安裝工件都綁定到一個確切的依賴鏈：通過設計，它不會允許你替換Jython for

Python給定的包。你當然可以使用conda來構建一個Jython軟件棧，但是每個包都需要一個新的特定于Jython的安裝工件 -

這就是為了保持conda用戶所依賴的嚴格依賴鏈所需要的。

Pip在這里更靈活，但一旦成本是它無法精確定義和解決依賴關系conda。

最后，對pip和conda的關注完全錯過了大量的Python代碼的目的設計的重新分配器。從平臺特定的軟件包管理器，如apt，yum，macports和homebrew到像bento，buildout，hashdist和spack這樣的跨平臺工具，有很多特定的包裝解決方案，旨在安裝Python(和其他)特定用戶。對于我們來說，像Python包裝管理局那樣，不是作為pip

/

PyPI的競爭對手，而是作為下游工具，可以利用所有開發和維護pip，PyPI的所有人的英勇努力，這將是更有成果的，和相關工具鏈。

到哪里去?

因此，似乎我們剩下兩種不同的包裝解決方案，但是對于許多Python用戶來說，它們具有廣泛的重疊(即在隔離環境中安裝Python包時)。那么社會應該從這里走?我認為我們可以做的主要事情是確保項目(1)盡可能一起工作，和(2)相互學習有點。

Conda

如上所述，conda已經有一個完全打開的工具鏈，并且處于一個穩定的趨勢，完全開放的包(但不完全在那里)。一個明顯的方向是通過conda-forge推進社區發展和維護conda堆棧，或許最終使用它來代替conda當前的默認通道。

在我們推進這一點時，我相信，conda和conda-forge社區可以從模仿Python包裝管理局的明確和開放的治理模式中受益。例如，PyPA有一個開放的治理模式，明確的目標，新的發展和功能的清晰的路線圖，以及明確的溝通和討論的渠道，以及從根本上社區監督完整的pip

/ PyPI系統。

另一方面，對于conda和conda-forge，代碼(以及很快所有的配方)是開放的，但是系統的治理和控制模型遠不夠明確。鑒于conda的重要性，特別是在PyData社區，它將有益于所有這一點澄清這一點

- 也許在NumFOCUS組織的保護下。

話雖如此，參與conda-forge的人告訴我，核心團隊目前正在解決這個問題，包括生成管理文件，行為準則和加強提案框架。

PyPI / pip

雖然Python包索引似乎有其治理的秩序，有一些方面的conda /

conda偽造，我認為將有益于它。例如，目前大多數Python包可以通過幾個步驟加載到conda-forge：

在網絡上的某個地方發布公共代碼版本(在github，bitbucket，PyPI等)

創建指向此代碼并列出依賴關系的配方/元數據文件

在conda-forge / staged-recipes上打開一個pull請求

就是這樣。一旦pull請求合并，在Windows，OSX和Linux上的二進制版本將自動創建并加載到conda-forge通道。此外，通過github透明地管理和更新軟件包，其中軟件包更新可以由合作者審核，并在CI系統上線之前進行測試。

我發現這個過程比發布到PyPI的(通過比較相對不透明的和手動的)過程更好，這主要由在本地終端處私人工作的單個用戶來完成。也許PyPI可以利用conda-forge的現有構建系統，并創建一個選項來自動構建多平臺輪和源分發，并在一個透明的命令中自動推送到PyPI。這絕對是一種可能性。

總結

以上是生活随笔為你收集整理的anaconda中的python如何进行关联分析_Anaconda、Miniconda、Conda、pip的相互关系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。