conda与anaconda

Conda: Myths and Misconceptions | Pythonic Perambulations (jakevdp.github.io)

以上为翻译来源。

误区 #1：Conda 是一个发行版，而不是一个包管理器

现实：Conda 是包管理器;Anaconda是一种软件分发。虽然Conda与Anaconda打包在一起，但两者是具有不同目标的不同实体。

软件分发是可在系统上安装和使用的预构建和预配置的包集合。 包管理器是一种自动执行安装、更新和删除包过程的工具。 Conda 及其 “”、“” 和 “” 子命令完全属于第二个定义：它是一个包管理器。

conda install
conda remove

也许这里的困惑来自于Conda与两个软件发行版紧密耦合的事实：Anaconda和Miniconda。Anaconda是PyData生态系统中中央软件的完整发行版，包括Python本身以及数百个第三方开源项目的二进制文件。Miniconda 本质上是一个空 conda 环境的安装程序，仅包含 Conda 及其依赖项，因此您可以从头开始安装所需的内容。

但不要搞错：Conda 与 Anaconda/Miniconda 和 Python 本身一样不同，并且（如果你愿意）可以在不接触 Anaconda/Miniconda 的情况下安装。 有关其中每个的更多信息，请参阅 conda 常见问题解答。

迷思#2：Conda是一个Python包管理器

现实：Conda 是一个通用的包管理系统，旨在构建和管理来自任何语言的任何类型的软件。因此，它也适用于Python包。

因为 conda 起源于 Python（更具体地说是 PyData）社区，所以许多人错误地认为它本质上是一个 Python 包管理器。 事实并非如此：conda 旨在管理任何软件堆栈中的包和依赖项。 从这个意义上说，它不像pip，更像是apt或yum的跨平台版本。

如果你使用 conda，你可能已经在利用许多非 Python 包了;以下命令将列出环境中的那些：

$ conda search --canonical  | grep -v 'py\d\d'

迷思#3：Conda和pip是直接竞争对手

现实：Conda 和 pip 服务于不同的目的，并且只在一小部分任务中直接竞争：即在隔离环境中安装 Python 包。

Pip，代表P ip Installs Packages，是Python官方认可的包管理器，最常用于安装Python包索引（PyPI）上发布的包。pip 和 PyPI 都由 Python Packaging Authority （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的Zen，当用Python做任何事情时，“应该有一个 - 最好只有一个 - 明显的方法来做到这一点。那么，为什么创造者会通过引入一种安装Python包的新方法来混淆这个领域呢？为什么他们不回馈Python社区并改进以克服其缺陷？condapip

事实证明，这正是他们所做的。在 2012 年之前，PyData/SciPy 生态系统的开发人员在 Python 社区开发的包管理解决方案的限制下竭尽全力工作。 早在 2001 年，NumPy 项目就分叉了 distutils，试图让它处理 NumPy 发行版的复杂需求。 他们将NETLIB的很大一部分捆绑到一个单片的Python包中（你可能知道这是SciPy），实际上创建了一个分发即python包，以规避Python的分发工具无法以任何有意义的方式管理这些额外的Python依赖项的事实。 整整一代科学 Python 用户花了无数个小时与这种将方形钉子强行插入圆孔的练习所创造的安装地狱作斗争——而这些人只是那些幸运地使用 Linux 的人。 如果你在Windows上，那就忘掉它吧。 要了解这些痛点以及它们如何导致Conda的一些细节，我建议Travis Oliphant在2013年关于该主题的博客文章。

但是，为什么 Conda 的创建者不与 Python 打包人员交谈并一起解决这些挑战呢？事实证明，他们做到了。

Conda的起源是在Guido van Rossum受邀在2012年首届PyData聚会上发言之后;在关于打包困难的问答中，他告诉我们，当涉及到打包时，“与更大的Python社区相比，你的需求听起来真的很不寻常，你最好构建自己的需求”（参见本次讨论的视频）。 即使在遵循BDFL的这些建议的同时，PyData社区仍在继续与核心Python开发人员就该主题进行对话和合作：另一个公开的例子是CPython核心开发人员Nick Coghlan邀请他在SciPy 2014上发表主题演讲（在此处观看视频）。他做了一个精彩的演讲，专门讨论了软件分发的“未解决的问题”背景下的pip和conda，并提到了根据特定用户的需求量身定制多种分发方式的价值。

Nick 和 Python Packaging Authority 的其他人并没有暗示 Conda 是分裂的，而是正式承认 Conda 是 Python 代码的许多重要再分发者之一，并且正在努力更好地使这些工具能够与 Python 包索引无缝协作。

迷思#5：conda不适用于virtualenv，因此对我的工作流程毫无用处

现实：你实际上可以在 virtualenv 中安装（一些）conda 包，但更好的是使用 Conda 自己的环境管理器：它与 pip 完全兼容，并且比 virtualenv 有几个优势。

virtualenv/venv 是允许用户创建与 . Conda 有自己的内置环境管理器，可以与 Conda 和 pip 无缝协作，实际上与 virtualenv/venv 相比有几个优势：pip

• conda 环境集成了不同 Python 版本的管理，包括 Python 本身的安装和更新。Virtualenvs 必须在现有的外部管理的 Python 可执行文件上创建。
• Conda 环境可以跟踪非 Python 依赖项;例如，无缝管理基本工具（如LAPACK或OpenSSL）的依赖项和并行版本
• 与建立在符号链接上的环境不同 - 它打破了virtualenv的隔离，有时对于非Python依赖项来说可能是脆弱的 - conda-env是单个可执行路径中真正的隔离环境。
• 虽然 virtualenvs 与 conda 包不兼容，但 conda 环境与 pip 包完全兼容。首先，然后您可以在该环境中使用任何可用的包。您甚至可以在 conda 环境文件中显式列出 pip 包，这意味着完整的软件堆栈完全可以从单个环境元数据文件重现。conda install pippip install

也就是说，如果您想在虚拟环境中使用 conda，则可以：

$ virtualenv test_conda

$ source test_conda/bin/activate

$ pip install conda

$ conda install numpy

这会在虚拟环境中安装 conda 支持 MKL 的 NumPy 包。 我不建议这样做：我找不到此功能的文档，结果似乎相当脆弱 - 例如，尝试在virtualenv中以非常不优雅和不可恢复的方式失败，似乎与Virtualenv架构背后的符号链接有关。 这似乎不是 conda 和 virtualenv 之间的一些根本不兼容，而是与构建过程中的一些细微不一致有关，因此可能是可以修复的（例如，请参阅 conda 问题 1367 和 anaconda 问题 498）。conda update python

如果要避免这些困难，更好的主意是创建一个新的 conda 环境来安装 conda 包。 对于习惯了 // 命令语法但想要尝试 conda 的人，conda 文档包括 和 / 命令之间的转换表。pip install condapipvirtualenvvenvcondapipvirtualenv

迷思#6：现在pip使用轮子，不再需要conda了

现实：车轮只是推动 conda 开发的众多挑战之一，而车轮也有 Conda 二进制文件解决的弱点。

推动 Conda 创建的一个困难是 pip 只能分发源代码，而不能分发预编译的二进制发行版，对于构建 NumPy 和 SciPy 等扩展密集型模块的用户来说，这个问题尤其具有挑战性。 在 Conda 以自己的方式解决了这个问题之后，pip 本身增加了对轮子的支持，这是一种二进制格式，旨在解决 . 在通用工具中解决了这个问题后，Conda 早期采用者现在不应该蜂拥而至吗？pip

不一定。跨平台二进制文件的分发只是 conda 中解决的众多问题之一。 编译的二进制文件突出了 conda 的另一个基本部分：有意义地跟踪非 Python 依赖项的能力。 由于 pip 的依赖跟踪仅限于 Python 包，因此在轮子中执行此操作的主要方法是将已发布的依赖项版本与 Python 包二进制文件捆绑在一起，这使得更新此类依赖项变得痛苦（想到了 OpenSSL 的最新安全更新）。此外，conda 包括一个真正的依赖解析器，这是 pip 目前缺少的组件。

对于科学用户来说，conda还允许将构建链接到优化的线性代数库，就像Continuum使用其免费提供的MKL支持的NumPy / SciPy一样。 Conda 甚至可以分发非 Python 构建需求，例如 ，这大大简化了在其分发的预编译二进制文件之上构建其他包的过程。 如果您尝试使用 pip 的轮子来执行此操作，您最好希望您的系统具有与最初用于构建相关轮子的编译器和设置兼容的编译器和设置。gcc

迷思#7：conda不是开源的;它与一家营利性公司有关，该公司可以随时开始收取服务费用。

现实：conda（包管理器和构建系统）是100%开源的，Anaconda（发行版）也几乎在那里。

在开源世界中，对营利性实体存在（有时非常正确的）基本不信任，而Anaconda是由Continuum Analytics创建的，并且是大型企业产品的免费组件这一事实引起了一些人的担忧。

让我们抛开这样一个事实，在我看来，Continuum是为数不多的几家真正以正确的方式做开放软件的公司之一（另一个话题）。 忽略这一点，事实是Conda本身 - 提供以跨平台方式构建，分发，安装，更新和管理软件的实用程序的包管理器 - 是100%开源的，可在GitHub和BSD许可上获得。 即使对于 Anaconda（发行版），EULA 也只是一个标准的 BSD 许可证，用于创建 Anaconda 的工具链也是 100% 开源的。 简而言之，使用Conda时无需担心知识产权问题。

如果 Anaconda/Miniconda 发行版仍然让您担心，请放心：您不需要安装 Anaconda 或 Miniconda 即可获得，尽管这些都是使用它的便捷途径。 正如我们在上面看到的，你可以“”通过PyPI安装它，而无需接触Continuum的网站。condapip install conda

迷思#8：但是Conda软件包本身是闭源的，对吧？

现实：虽然 conda 的默认渠道尚未完全开放，但社区主导的努力（Conda-Forge）使 conda 包装和分销完全开放。

从历史上看，默认 conda 通道的包构建过程并没有尽可能开放，并且更新构建的过程主要依赖于了解 Continuum 中的某个人。 有传言说，这主要是因为最初的 conda 包创建过程不像今天这样定义明确和简化。

但这种情况正在改变。Continuum 正在努力打开他们的软件包配方，有人告诉我，500+ 个软件包中只有几十个有待移植。这几个食谱是Anaconda发行版中唯一剩下的一块没有完全开放的。

如果这还不够，那么在2016年初推出了一个新的社区主导的 - 不是Continuum附属的 - 项目，称为conda-forge，其中包含用于为任何软件包创建社区驱动构建的工具。 软件包通过github进行开放维护，二进制文件使用免费的CI工具自动构建，如TravisCI for Mac OSX构建，AppVeyor用于Windows构建和CircleCI for Linux构建。 每个包的所有元数据都存在于 Github 存储库中，包更新是通过合并 Github 拉取请求来完成的（下面是 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 index 是相关命令）。 鉴于 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 代替 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-forge 推动社区开发和维护 conda 堆栈，也许最终使用它来取代 conda 当前的默认通道。

在我们推进这项工作的过程中，我相信 conda 和 conda-forge 社区可以从模仿 Python Packaging Authority 清晰开放的治理模型中受益。 例如，PyPA 有一个开放的治理模型，有明确的目标，有明确的开发和功能路线图，有明确的沟通和讨论渠道，以及社区从头开始监督整个 pip/PyPI 系统。

另一方面，对于 conda 和 conda-forge，代码（以及很快的所有配方）是开放的，但系统的治理和控制模型远没有那么明确。 鉴于 conda 在 PyData 社区中的重要性，以某种方式澄清这一点将有利于所有这些——也许是在 NumFOCUS 组织的保护伞下。

话虽如此，参与conda-forge的人告诉我，核心团队目前正在解决这个问题，包括生成管理文件，行为准则和增强建议框架。

PyPI/pip

虽然 Python 包索引似乎有其治理顺序，但我认为 conda/conda-forge 的某些方面会有利于它。 例如，目前大多数 Python 包只需几个步骤即可加载到 conda-forge 中：

1. 在网络上的某个地方发布公共代码版本（在github，bitbucket，PyPI等上）
2. 创建指向此代码并列出依赖项的配方/元数据文件
3. 在 conda-forge/staged-recipes 上打开拉取请求

仅此而已。一旦拉取请求被合并，Windows、OSX 和 Linux 上的二进制构建就会自动创建并加载到 conda-forge 通道。 此外，通过 github 透明地管理和更新包，协作者可以在包更新上线之前由 CI 系统对其进行审查和测试。

我发现这个过程比发布到 PyPI 的过程（相比之下相对不透明和手动）要好得多，后者主要由在本地终端私下工作的单个用户完成。 也许 PyPI 可以利用 conda-forge 现有的构建系统，并创建一个选项来自动构建多平台轮子和源代码分发，并在单个透明命令中自动将它们推送到 PyPI。这绝对是一种可能性。

后记：我应该使用哪种工具？

我希望我已经说服了你，conda 和 pip 在 Python 社区中都扮演着重要的角色。有了这个，如果你刚开始，你应该使用哪个？答案取决于你想做什么：

如果你有一个现有的系统Python安装，并且你想在其中或上面安装软件包，请使用pip+virtualenv。例如，也许您使用或其他系统包管理器来安装 Python，以及一些链接到系统工具的包，这些包（尚）无法通过 conda 或 pip 轻松安装。Pip+virtualenv 将允许您安装新的 Python 包并在现有发行版之上构建环境，并且您应该能够依赖您的系统包管理器来处理任何难以安装的依赖项。apt

如果您想灵活地管理多语言软件堆栈并且不介意使用隔离环境，请使用 conda。Conda 的多语言依赖管理和跨平台二进制安装可以做 pip 无法做到的事情。 一个巨大的好处是，对于大多数软件包，结果将立即与多个操作系统兼容。

如果你想在隔离环境中安装 Python 包，pip+virtualenv 和 conda+conda-env 大多是可以互换的。这是两个工具以自己的方式发光的重叠区域。话虽如此，在这种情况下，我更喜欢 conda：Conda 对多个并行 Python 环境的统一、跨平台、全栈管理以及强大的依赖管理已被证明是我的研究、教学和软件开发工作中令人难以置信的节省时间。 此外，我发现我和同事的需求更经常偏离 conda 的优势领域（非 Python 工具和依赖项的管理），而不是 pip 的优势领域（与环境无关的 Python 包管理）。