conda如何在内部工作？

Question

我现在搜索了一会儿,但找不到任何满意的答案:

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

此外,因为它是python不可知的并且显然工作得非常好和流利,为什么它不被用作apt或yum的通用包管理器？

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

或者相反,为什么例如apt和yum无法提供conda提供的功能？conda比那些包管理员"更好"还是只是不同？

谢谢你的任何提示!

Answer 1

我在SciPy 2014演讲中解释了很多这方面的内容.让我在这里给出一点概述.

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

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

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

当conda安装它时,它会将tarball提取到pkgs目录并将文件硬链接到安装环境中.最后,一些具有一些硬编码安装路径的文件已被替换(通常是shebang行).

基本上就是这样.在依赖性解析方面还有更多的东西,但是一旦它知道它将要安装什么包,它就是这样做的.

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

回答你的其他问题:

此外,因为它是python不可知的并且显然工作得非常好和流利,为什么它不被用作apt或yum的通用包管理器？

You certainly can. The only thing limiting this are the set of packages that have been built for conda. On Windows, this is a very nice option, as there aren't any system package managers like there are on Linux.

What are the restrictions of using only conda as package manager? Would it work?

It would work, assuming you have conda packages for everything you are interested in. The main restriction is that conda only wants to install things into the conda environment itself, so things that require specific installation locations on the system might not be well suited to conda (although it's still doable, if you set that location as your environment path). Or for instance, conda might not be a suitable replacement for "project level" package managers like bower.

Also, conda probably shouldn't be used to manage system level libraries (libraries that must be installed in the / prefix), like kernel extensions or the kernel itself, unless you were to build out a distribution that uses conda as a package manager explicitly.

The main thing I will say about these things is that conda packages are generally made to be relocatable, meaning the installation prefix of the package does not matter. This is why hard coded paths are changed as part of the install process, for instance. It also means that dynamic libraries built with conda build will have their RPATHs (on Linux) and install names (on OS X) changed automatically to use relative paths instead of absolute ones.

Or the other way round, why are e.g. apt and yum not able to provide the functionality conda provides? Is conda "better" than those package manager or just different?

In some ways it's better, and in some ways it's not. Your system package manager knows your system, and there are packages in there that are not going to be in conda (and some, like the kernel, that probably shouldn't be in conda).

The main advantage of conda is its notion of environments. Since packages are made to be relocatable, you can install the same package in multiple places, and effectively have completely independent installs of everything, basically for free.

Does it use some kind of containerization

No, the only "containerization" is having separate install directories and making packages relocatable.

or static linking of all the dependencies,

The dependency linking is completely up to the package itself. Some packages statically link their dependencies, some don't. The dynamically linked libraries have their load paths changed as I described above to be relocatable.

why is it so "cross platform"?

"Cross platform" in this case means "cross operating system". Although the same binary package can't work across OS X, Linux, and Windows, the point is that conda itself works identically on all three, so if you have the same packages built for all three platforms, you can manage them all the same way regardless of which one you are on.