python - Conda(基础)环境是否应该保持最新？

Question

我很高兴使用 Conda通过 miniconda安装以管理 python 环境。

安装后，我不理会 base 环境，而是为新项目创建新环境。然后我根据需要 conda env update 这些环境。但是，我不确定这是正确的方法。

base 环境是否应该在创建新环境之前conda env update？

我认为这会降低磁盘使用率，因为我可能不正确的理解是，Conda 在创建新环境时将包链接到 base 环境，如果包和依赖项完全相同匹配。

尽管...这没有多大意义，因为它们很容易失去同步。也许它只是节省了带宽，因为可以复制而不是下载匹配的包？

如果每个项目都有自己的环境，base 环境是否保持最新是否重要？

Answer 1

Conda 将所有包链接到 pkgs 文件夹，该文件夹由所有 envs 共享，并且不以任何特殊方式与 base 相关联。每当任何 env 安装或升级包时，它们都会去那里，并且没有任何明确的努力从现有包中获取资源——如果依赖项解决程序恰好解析为缓存包，它将使用它。目前，没有维持环境间包同步的机制，因此必须设计一个工作流来实现它。

潜在的工作流程

理论上，可以使用 Conda's env cloning最大化包版本同步。为此，您可以在概念上将您的环境分为三类:

• base env:仅用于核心基础设施，例如conda、jupyter、git等。 . 每当您需要新的命令行软件或需要 conda update conda 时，您都可以自由更新。它应该与其他环境几乎没有重叠。
• template env:集中了常用的包集，通常按版本限制分组。例如，对于您可能需要的不同 Python 版本，可能有 py27-tmpl、py36-tmpl 和 py37-tmpl不同的项目。在这里，您将安装跨项目所需的最大公共(public)包子集。模板环境的主要目的是制作...
• project env:与特定的开发项目相关联，最初派生为模板 env 的克隆。其中大部分核心软件都来自于模板，然后需要在这里安装额外的软件。一旦你为一个项目启动了一个，你就保持它相对固定，以保持开发的稳定性。

这样的结构将最大限度地重用现有的包版本。从 Conda v4.7 开始，依赖项解决程序默认使用隐式 --freeze-installed|--no-update-deps 标志进行第一阶段解决，该标志尝试安装请求的包而不不得不改变现有的包。如果与模板环境保持同步是您的目标，那么您可能希望在安装时始终使用 --freeze-installed。也可以使用 package pinning这明确地阻止指定的包从模板升级。但是，这可能会限制安装其他软件包的某些最新版本。

不幸的是，您仍然会遇到与直觉相似的同步问题:虽然您可以在制作新克隆之前更新这些模板环境，但不会更新之前从它们派生的环境。但是对于项目环境，我认为最好的做法是一旦开始工作就不要操纵它们。如果您关心空间，没有什么可以替代完成您的模块化项目，然后在使用后归档和删除项目环境。那，偶尔运行 conda clean。