14

我现在搜索了一段时间，但找不到任何满意的答案：

conda ( http://conda.pydata.org ) 如何在内部工作？欢迎任何细节...

此外，由于它与 python 无关，而且显然工作得很好而且很流畅，为什么它不用作像 apt 或 yum 这样的通用包管理器？

仅使用 conda 作为包管理器有什么限制？它会起作用吗？

或者反过来，为什么 apt 和 yum 不能提供 conda 提供的功能？conda 比那些包管理器“更好”还是只是不同？

感谢您的任何提示！

4

3 回答 3

24

我在我的SciPy 2014 演讲中解释了很多。让我在这里给出一个小轮廓。

首先，conda 包非常简单。它只是要安装的文件的压缩包，以及info目录中的一些元数据。例如 conda 包python是文件的 tarball

info/
    files
    index.json
    ...
bin/
    python
    ...
lib/
    libpython.so
    python2.7/
        ...
    ...
...

pkgs通过查看 Anaconda目录中提取的包，您可以确切地看到它的样子。完整的规范位于https://docs.conda.io/projects/conda-build/en/latest/source/package-spec.html。

当 conda 安装它时，它会将 tarball 解压缩到pkgs目录并将文件硬链接到安装环境中。最后，一些具有硬编码安装路径的文件已被替换（通常是 shebang 行）。

基本上就是这样。在依赖解析方面还有更多的事情发生，但是一旦它知道它将安装哪些软件包，它就是这样做的。

构建包的过程稍微复杂一些。@mattexx 的答案及其链接的文档描述了使用 conda build 构建包的一些规范方法。

要回答您的其他问题：

此外，由于它与 python 无关，而且显然工作得很好而且很流畅，为什么它不用作像 apt 或 yum 这样的通用包管理器？

你当然可以。唯一限制这一点的是为 conda 构建的软件包集。在 Windows 上，这是一个非常好的选择，因为没有像 Linux 上那样的系统包管理器。

仅使用 conda 作为包管理器有什么限制？它会起作用吗？

假设您对所有您感兴趣的东西都有 conda 包，它会起作用。主要限制是 conda 只想将东西安装到 conda 环境本身中，因此需要系统上特定安装位置的东西可能不太适合 conda （尽管它仍然可行，如果您将该位置设置为您的环境路径）。或者例如，conda 可能不是像 bower 这样的“项目级”包管理器的合适替代品。

此外，conda 可能不应该用于管理系统级库（必须安装在/前缀中的库），例如内核扩展或内核本身，除非您要构建一个明确使用 conda 作为包管理器的发行版。

关于这些事情我要说的主要是 conda 包通常是可重定位的，这意味着包的安装前缀无关紧要。例如，这就是为什么硬编码路径会在安装过程中更改的原因。这也意味着使用 conda build 构建的动态库将自动更改其 RPATH（在 Linux 上）和安装名称（在 OS X 上）以使用相对路径而不是绝对路径。

或者反过来，为什么 apt 和 yum 不能提供 conda 提供的功能？conda 比那些包管理器“更好”还是只是不同？

在某些方面它更好，在某些方面它不是。您的系统包管理器知道您的系统，并且其中有一些包不会出现在 conda 中（有些包，比如内核，可能不应该出现在 conda 中）。

conda 的主要优点是它的环境概念。由于软件包是可重定位的，因此您可以在多个位置安装同一个软件包，并且可以有效地完全独立安装所有内容，基本上是免费的。

它是否使用某种容器化

不，唯一的“容器化”是拥有单独的安装目录并使软件包可重定位。

或所有依赖项的静态链接，

依赖链接完全取决于包本身。有些包静态链接它们的依赖项，有些则没有。如上所述，动态链接库的加载路径已更改为可重定位。

为什么这么“跨平台”？

在这种情况下，“跨平台”是指“跨操作系统”。虽然相同的二进制包不能在 OS X、Linux 和 Windows 上运行，但关键是 conda 本身在这三个平台上的运行方式相同，所以如果你为所有三个平台构建了相同的包，你可以对它们进行相同的管理方式不管你在哪一个。

于 2015-01-26T23:40:39.983 回答
3

我不是软件方面的专家，但几个月来我一直在使用 conda 维护内部存储库，因此我可以分享一个“高级用户”的见解。这里有很多问题，所以我会尝试按顺序回答。

conda ( http://conda.pydata.org ) 如何在内部工作？欢迎任何细节...

我可以分享的最简洁的参考资料是conda-build doc，它详细解释了 conda 配方。

TL;DR Recipes 是带有配置文件的文件夹，该文件meta.yaml根据名称、版本、源位置、依赖项（构建、测试、运行）和安装后要运行的基本测试来描述包。它还包含构建脚本（build.sh和/或bld.bat分别用于 linux 和 win），它们执行除下载源之外的任何构建步骤。

安装包括（简而言之）下载源代码、创建构建环境、构建、创建测试环境和测试。您可以在系统范围内安装某些东西或将其安装在环境中：

conda install -n myenv mypkg # install only in myenv
conda install mypkg # install globally

激活环境的工作方式与使用 virtualenv 完全相同：

source activate myenv

仅使用 conda 作为包管理器有什么限制？它会起作用吗？

它会起作用的。如果你有一个支持你的环境的配方，你可以使用 conda 安装任何你想要的东西。您将遇到的问题是包支持。Conda 维护者和用户已经在各种渠道上创建了一个包生态系统，但对二进制包的支持几乎仅限于 Python 包通常需要的那些包，其中许多只在一个或两个平台上得到支持。apt、yum 等用户为各自的平台维护各种东西。

在我们的例子中，我们需要支持 Ubuntu 和 OSX，所以我们通过 puppet 和其他愚蠢的巫术维护了很多平台依赖的二进制包，我们使用 conda 来维护这两个平台的 Python 包。如果我们使用的所有二进制包都存在 conda 包，我可能会考虑使用 conda 代替 apt、brew 等，但如果我们使用的配方已经过时，我将冒险进行大量的配方维护。在 Python 包管理的情况下，这对我们来说很好，conda 填补了一个巨大的空白，但我还没有准备好对我们有现有工具要维护的包进行处理。我们会看看我的想法是否会随着 conda 生态系统的成熟而改变。一个统治它们的工具会很好，但我认为 conda 还没有准备好让我实现这一目标。

它是否使用某种容器化，或所有依赖项的静态链接，为什么它如此“跨平台”？

“跨平台”可以有很多含义。对于 Python 包，跨平台意味着您可以使用任何版本的 python 和您需要的包创建环境。对于 Linux/win 风格和发行版，您可以根据环境在构建脚本中做尽可能多的事情。例如，看一下qt 的 conda 构建脚本。它具有适用于 OSX 和 Linux 的适当安装。脚本可以为所欲为。您可以根据操作系统版本或任何您想要的切换。如果不支持安装平台，许多配方将简单地失败。

希望你觉得这很有帮助。

于 2015-01-03T18:21:01.147 回答
1

我看到没有一个真正了解 conda 工作原理的人愿意分享他们的知识。这是不幸的...

我可以提供高级别的conda build动作序列：

  1. 查看 meta.yaml 以找到 RUN + BUILD 依赖项
  2. 创建名为“_build”的新环境
    1. 从 meta.yaml 安装 RUN + BUILD 依赖项
  3. 获取源代码到 conda_bld/work
  4. 构建包：
    1. 拍摄完整环境的“快照1”
    2. home_dir：'conda_bld/work'，运行：'sh build.sh''setup.py install conda_bld/work'（将本地安装到 _build env）
    3. 拍摄完整环境的“快照2”
    4. 包内容是'diff snapshot1 snapshot2'
  5. 运行测试：
    1. 使用 '{just built package, RUN DEPS}' 创建 '_test' ENV
    2. 运行测试

这与侧面的@asmeurer youtube 链接应该可以帮助您入门。

于 2016-10-05T13:32:21.980 回答