在 CONDA 环境中专门使用 PIP 有哪些陷阱？

Question

官方文档和此博客位于同一网站 - 建议安装尽可能多的需求，conda然后使用 pip。显然这是因为conda将不知道对依赖项所做的任何更改pip，因此无法正确解析依赖项。

现在，如果一个人专门使用pip并且不安装任何东西conda，那么似乎有理由期望conda不需要知道所做的任何更改pip- 因为conda实际上变成了一个隔离依赖项和管理版本的工具。然而，这违背了官方建议，因为人们不会安装尽可能多的要求conda。

所以问题仍然存在：在环境中专门使用是否有任何已知的缺点？pipconda

此处触及了一些类似的主题，但不涵盖专门在环境中使用的情况。我也来过这里：pipconda

Answer 1

不确定能否对此给出全面的答案，但我想到的一些主要问题是：

缺乏对非Python依赖解析的深度支持。虽然随着时间的推移，已经有更多捆绑非 Python 资源的轮子可用，但它远不及 Conda 作为通用包管理器而不是特定于 Python 所提供的覆盖范围。对于任何从事互操作计算（例如，reticulate）的人来说，我希望 Conda 会受到青睐。
优化的库。与第一点有点相关，但 Anaconda 团队已经努力构建软件包的优化版本（例如，MKL for numpy）。不确定 PyPI 是否提供同等功能。¹
跨环境的冗余浪费。当包和环境位于同一卷上时，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
```
Run Code Online (Sandbox Code Playgroud)
用它来重建环境。

综上所述，我可以很容易地想象到，这些对某些人来说都不重要（大多数都是为了方便），尤其是那些倾向于纯粹使用 Python 工作的人。然而，在这种情况下，我不明白为什么人们不完全放弃 Conda 并使用特定于 Python 的虚拟环境管理器。

_{[1]如果您不知道，请纠正我。}