python - 在 CONDA 环境中独占使用 PIP 有哪些陷阱？

Question

背景

官方documentation还有这个blog在同一网站中 - 建议使用 conda 安装尽可能多的要求，然后使用 pip。显然这是因为 conda 将不知道 pip 对依赖项所做的任何更改，因此将无法正确解析依赖项。

问题

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

所以问题仍然存在:在 conda 环境中独占 使用 pip 是否有任何已知缺 pip ？

类似主题

here 中的类似主题已触及但不包括在 conda 环境中专门使用 pip 的情况。我也来过这里:

• Specific reasons to favor pip vs. conda when installing Python packages
• What is the difference between pip and conda?
• Using Pip to install packages to Anaconda Environment

Answer 1

不确定是否可以就此给出全面的答案，但我想到的一些主要事情是:

1. 缺乏对非 Python 依赖解析的深度支持。随着时间的推移，越来越多的捆绑非 Python 资源的轮子变得可用，但它远不及 Conda 作为通用包管理器而不是特定于 Python 的包管理器所提供的覆盖范围。对于任何进行互操作计算(例如，reticulate)的人，我希望 Conda 会受到青睐。

2. 优化库。与第一 pip 有 pip 相关，但 Anaconda 团队已努力构建包的优化版本(例如，numpy 的 MKL)。不确定是否可以通过 PyPI 获得等效项。¹

3. 跨环境的浪费冗余。当包和环境位于同一卷上时，Conda 使用硬链接(hard link)，并支持跨卷的软链接(soft link)。这有助于最大限度地减少复制安装在多个环境中的任何包。

4. 使导出复杂化。导出 (conda env export) 时，Conda 不会选择所有 pip 安装的包 - 只有来自 PyPI 的包。也就是说，它会丢失从 GitHub 等安装的东西。如果确实采用 pip-only 路线，我认为更可靠的导出策略是使用 pip freeze > requirements.txt，然后制作一个类似的 YAML

   channels:
     - defaults
   dependencies:
     - python=3.8  # specify the version
     - pip
     - pip:
       - -r requirements.txt
   

   用它来重建环境。

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

---

_{[1]如有不明之处请指正。}