是的，conda比virtualenv更容易安装，并且基本上取代了后者。

我在公司工作，在几道防火墙后面的机器上，我没有管理权限

在我有限的python使用经验(2年)中，我遇到过一些库(JayDeBeApi,sasl)在通过pip安装时抛出c++依赖错误 错误:需要Microsoft Visual c++ 14.0。通过“Microsoft Visual c++ Build Tools”获取:http://landinghub.visualstudio.com/visual-cpp-build-tools

这些安装与conda很好，因此，从那些日子起，我开始与conda env合作。 然而，阻止conda在我没有写权限的c.programfiles中安装依赖并不容易。

毫无疑问，Conda拥有更好的API。但是，我想谈谈使用conda的缺点，因为conda在其他答案中也有它的荣耀:

解决环境问题——conda环境后面的一个大刺。作为补救措施，建议您不要使用conda-forge通道。但是，由于它是最流行的通道，而且一些包(不仅仅是微不足道的包，甚至是非常重要的包，如pyspark)在conda-forge上独家可用，你很快就会陷入困境。 包装环境是一个问题

还有其他已知的问题。Virtualenv是一个上坡路，但路上很少有墙。另一方面，conda，在我的印象中，偶尔有这些硬墙，你只需要深吸一口气，使用virtualenv

Conda取代virtualenv。在我看来，这样更好。它不局限于Python，也可以用于其他语言。根据我的经验，它提供了更流畅的体验，特别是对于科学软件包。我第一次在Mac上正确安装MayaVi是用conda。 你仍然可以使用pip。事实上，conda会在每个新环境中安装pip。它知道pip安装包。

例如:

conda list

列出当前环境中所有已安装的包。 conda安装的包显示如下:

sphinx_rtd_theme          0.1.7                    py35_0    defaults

通过PIP安装的有< PIP >标记:

wxpython-common           3.0.0.0                   <pip>

是的，conda比virtualenv更容易安装，并且基本上取代了后者。

I use both and (as of Jan, 2020) they have some superficial differences that lend themselves to different usages for me. By default Conda prefers to manage a list of environments for you in a central location, whereas virtualenv makes a folder in the current directory. The former (centralized) makes sense if you are e.g. doing machine learning and just have a couple of broad environments that you use across many projects and want to jump into them from anywhere. The latter (per project folder) makes sense if you are doing little one-off projects that have completely different sets of lib requirements that really belong more to the project itself.

Conda创建的空环境大约是122MB，而virtualenv的大约是12MB，所以这是另一个你可能不喜欢到处散布Conda环境的原因。

最后，Conda更喜欢集中式env的另一个表面迹象是(同样是默认情况)，如果您在自己的项目文件夹中创建了Conda env并激活它，那么出现在shell中的名称前缀就是该文件夹的绝对路径(太长了)。你可以通过给它一个名字来解决这个问题，但是默认情况下virtualenv做的是正确的事情。

我预计随着两个包管理器争夺主导地位，这些信息将很快变得陈旧，但这些是今天的权衡:)

编辑:我在2021年4月再次审查了情况，情况没有变化。使用conda安装本地目录仍然很尴尬。