官方文档和该博客在同一网站上-建议先安装尽可能多的要求，conda然后再使用pip。显然，这是因为conda将不知道对依赖项所做的任何更改pip，因此将无法正确解析依赖项。
现在，如果一个人专有地使用pip并且不用安装任何东西conda，那么似乎可以合理地期望conda不需要知道由它进行的任何更改pip-因为conda有效地变成了隔离依赖关系和管理版本的单纯工具。但是，这与官方建议背道而驰，因为使用不会安装尽可能多的要求conda。
因此问题仍然存在：仅pip在conda环境中使用是否存在任何已知的缺点？
这里已经涉及了类似的主题，但是没有涵盖仅在环境中使用的情况。我也来过这里：pipconda
不确定是否可以对此提供全面的答案，但是想到的一些主要问题是：
缺乏对非Python依赖项解析的深入支持。随着时间的推移，越来越多的捆绑非Python资源的轮子已经可用，但作为通用软件包管理器而不是特定于Python的Conda所提供的覆盖范围还远远没有达到。对于进行互操作计算的任何人（例如reticulate），我希望Conda会受到青睐。
优化的库。有点与第一点有关，但是Anaconda团队已努力构建软件包的优化版本（例如MKL用于numpy）。不确定是否可以通过PyPI使用等效项。1个
跨环境浪费的冗余。当程序包和环境在同一卷上时，Conda使用硬链接，并支持跨整个卷的软链接。这有助于最大程度地减少复制在多个环境中安装的任何程序包。
出口复杂化。导出（conda env export）时，Conda不会提取所有已pip安装的软件包-仅提取来自PyPI的软件包。也就是说，它将丢失从GitHub等安装的内容。如果确实采用了仅pip路由，则我认为一种更可靠的导出策略是使用pip freeze > requirements.txt，然后将YAML改为
channels:
- defaults
dependencies:
- python=3.8 # specify the version
- pip
- pip:
- -r requirements.txt
用它来重新创建环境。
综上所述，我很容易想到，对于某些人（大多数人是方便），尤其是那些倾向于纯粹使用Python工作的人来说，这些都不重要。但是，在这种情况下，我不明白为什么不完全放弃Conda并使用Python特定的虚拟环境管理器。
[1]否则请有人纠正我。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句