在CONDA环境中仅使用PIP有哪些问题？
在CONDA环境中仅使用PIP有哪些问题？
背景
官方文档和同一网站上的博客推荐尽可能多地使用conda安装要求，然后再使用pip。显然，这是因为conda将不会察觉到由pip所做的任何依赖项更改，因此将无法正确解决依赖项。
问题
现在，如果一个人完全使用pip而不使用conda安装任何东西，似乎可以合理地期望conda不需要察觉pip所做的任何更改 - 因为conda实际上成为了一个仅用于隔离依赖项和管理版本的工具。然而，这与官方推荐相矛盾，因为一个人将不会使用conda安装尽可能多的要求。
因此，问题仍然存在：在conda环境中exclusively使用pip是否有任何已知的缺点？
类似主题
类似的主题在这里稍微提到过，但没有涵盖在conda环境中exclusively使用pip的情况。我也曾参考过以下问题：
在CONDA环境中仅使用PIP的缺点是什么？原因和解决方法如下：
原因：
1. PIP在非Python依赖解析方面的支持不够深入。虽然随着时间的推移，越来越多捆绑了非Python资源的wheel包变得可用，但与作为通用软件包管理器的Conda相比，覆盖范围远远不够。对于进行互操作计算的任何人（例如reticulate），我希望会更倾向于使用Conda。
2. 优化库。这与第一点有关，但Anaconda团队努力构建了一些优化版本的软件包（例如，用于numpy的MKL）。不确定是否可以通过PyPI获得相应的版本。
3. 环境之间的冗余浪费。当软件包和环境位于同一卷时，Conda使用硬链接，并支持跨卷的软链接。这有助于尽量减少在多个环境中安装的软件包的复制。
解决方法：
1. 导出时的复杂性。当导出（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特定的虚拟环境管理器。