其他答案对细节进行了合理的描述，但我想强调一些高级点。

PIP是一个包管理器，可以方便地安装、升级和卸载python包。它也适用于虚拟python环境。

Conda是任何软件(安装、升级和卸载)的包管理器。它还适用于虚拟系统环境。

conda设计的目标之一是方便用户所需的整个软件堆栈的包管理，其中一个或多个python版本可能只是一小部分。这包括低级库，如线性代数，编译器，如Windows上的mingw，编辑器，版本控制工具，如Hg和Git，或任何其他需要分发和管理的工具。

对于版本管理，pip允许您在多个python环境之间切换和管理。

Conda允许您在多个通用环境之间切换和管理，在这些环境中，许多其他东西的版本号可能不同，比如c库、编译器、测试套件或数据库引擎等等。

Conda不是以Windows为中心的，但在Windows上，当需要安装和管理需要编译的复杂科学包时，它是目前可用的最好的解决方案。

当我想到在Windows上通过pip编译许多这些包，或者在需要编译时调试失败的pip安装会话时，我浪费了多少时间，我想哭。

最后一点，Continuum Analytics还提供(免费的)binstar.org(现在叫anaconda.org)，允许常规的软件包开发人员创建他们自己的自定义(构建的!)软件堆栈，他们的软件包用户可以从中安装conda。

引用Conda: Myths and misconcepts(一个全面的描述):

...

误解3:Conda和pip是直接竞争对手

事实:Conda和pip服务于不同的目的，并且只在一小部分任务上直接竞争:即在孤立的环境中安装Python包。

Pip是Pip安装包的缩写，是Python官方认可的包管理器，最常用于安装发布在Python包索引(PyPI)上的包。pip和PyPI都由Python打包管理局(PyPA)管理和支持。

In short, pip is a general-purpose manager for Python packages; conda is a language-agnostic cross-platform environment manager. For the user, the most salient distinction is probably this: pip installs python packages within any environment; conda installs any package within conda environments. If all you are doing is installing Python packages within an isolated environment, conda and pip+virtualenv are mostly interchangeable, modulo some difference in dependency handling and package availability. By isolated environment I mean a conda-env or virtualenv, in which you can install packages without modifying your system Python installation.

Even setting aside Myth #2, if we focus on just installation of Python packages, conda and pip serve different audiences and different purposes. If you want to, say, manage Python packages within an existing system Python installation, conda can't help you: by design, it can only install packages within conda environments. If you want to, say, work with the many Python packages which rely on external dependencies (NumPy, SciPy, and Matplotlib are common examples), while tracking those dependencies in a meaningful way, pip can't help you: by design, it manages Python packages and only Python packages.

Conda和pip不是竞争对手，而是专注于不同用户组和使用模式的工具。

为了不让你们更困惑， 但是你也可以在conda环境中使用PIP，它会验证上面的一般管理器注释和特定于python的管理器注释。

conda install -n testenv pip
source activate testenv
pip <pip command>

您还可以将PIP添加到任何环境的默认包中，以便每次都显示它，这样您就不必遵循上面的代码段。

PIP是一个包管理器。

Conda既是包管理器，也是环境管理器。

细节:

依赖项检查

Pip and conda also differ in how dependency relationships within an environment are fulfilled. When installing packages, pip installs dependencies in a recursive, serial loop. No effort is made to ensure that the dependencies of all packages are fulfilled simultaneously. This can lead to environments that are broken in subtle ways, if packages installed earlier in the order have incompatible dependency versions relative to packages installed later in the order. In contrast, conda uses a satisfiability (SAT) solver to verify that all requirements of all packages installed in an environment are met. This check can take extra time but helps prevent the creation of broken environments. As long as package metadata about dependencies is correct, conda will predictably produce working environments.

参考文献

理解康达和皮普

其他答案对细节进行了合理的描述，但我想强调一些高级点。

PIP是一个包管理器，可以方便地安装、升级和卸载python包。它也适用于虚拟python环境。

Conda是任何软件(安装、升级和卸载)的包管理器。它还适用于虚拟系统环境。

conda设计的目标之一是方便用户所需的整个软件堆栈的包管理，其中一个或多个python版本可能只是一小部分。这包括低级库，如线性代数，编译器，如Windows上的mingw，编辑器，版本控制工具，如Hg和Git，或任何其他需要分发和管理的工具。

对于版本管理，pip允许您在多个python环境之间切换和管理。

Conda允许您在多个通用环境之间切换和管理，在这些环境中，许多其他东西的版本号可能不同，比如c库、编译器、测试套件或数据库引擎等等。

Conda不是以Windows为中心的，但在Windows上，当需要安装和管理需要编译的复杂科学包时，它是目前可用的最好的解决方案。

当我想到在Windows上通过pip编译许多这些包，或者在需要编译时调试失败的pip安装会话时，我浪费了多少时间，我想哭。

最后一点，Continuum Analytics还提供(免费的)binstar.org(现在叫anaconda.org)，允许常规的软件包开发人员创建他们自己的自定义(构建的!)软件堆栈，他们的软件包用户可以从中安装conda。

WINDOWS用户

“标准”包装工具的情况最近有所改善:

截至2015年9月11日，pypi本身的车轮包装数量为48%(2015年5月为38%，2014年9月为24%)， 最新的python 2.7.9版本现在支持开箱即用的wheel格式，

“标准”+“微调”包装工具的情况也在改善:

你可以在http://www.lfd.uci.edu/~gohlke/pythonlibs上找到几乎所有的科学软件包， mingwpy项目可能有一天会给Windows用户带来一个“编译”包，允许他们在需要的时候从源代码安装所有东西。

“Conda”包装对于它所服务的市场来说仍然更好，并强调了“标准”应该改进的地方。

(此外，在标准wheel系统和conda系统或buildout中的依赖规范multiple-effort不是很python化，如果所有这些打包“核心”技术可以通过某种PEP聚合在一起就好了)