condaは内部でどのように機能しますか？

これについては、SciPy2014のトークで詳しく説明します。ここで少し概要を説明しましょう。

まず、condaパッケージは本当にシンプルです。これは、インストールされるファイルのtarballであり、infoディレクトリ内のメタデータも含まれています。たとえば、のcondaパッケージpythonはファイルのtarballです。

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

Anacondapkgsディレクトリで抽出されたパッケージを見ると、どのように見えるかを正確に確認できます。完全な仕様はhttps://docs.conda.io/projects/conda-build/en/latest/source/package-spec.htmlにあります。

condaがこれをインストールすると、tarballがpkgsディレクトリに抽出され、ファイルがインストール環境にハードリンクされます。最後に、ハードコードされたインストールパスを持つ一部のファイルでは、これが置き換えられています（通常はシバン行）。

基本的にはそれだけです。依存関係の解決に関してはさらにいくつかのことが起こりますが、インストールするパッケージがわかれば、それがどのように行われるかです。

パッケージを構築するプロセスはもう少し複雑です。@mattexxの回答とリンク先のドキュメントでは、condabuildを使用してパッケージをビルドする標準的な方法について説明しています。

他の質問に答えるには：

さらに、Pythonにとらわれず、明らかに非常にうまく機能するので、aptやyumのような汎用パッケージマネージャーとして使用されないのはなぜですか？

あなたは確かにできます。これを制限する唯一のものは、conda用に構築されたパッケージのセットです。Linuxのようにシステムパッケージマネージャーがないため、Windowsではこれは非常に優れたオプションです。

パッケージマネージャーとしてcondaのみを使用する場合の制限は何ですか？それはうまくいくでしょうか？

興味のあるものすべてにcondaパッケージがあると仮定すると、機能します。主な制限は、condaはconda環境自体にインストールするだけなので、システムに特定のインストール場所が必要なものはcondaに適していない可能性があります。 （ただし、その場所を環境パスとして設定した場合は、引き続き実行可能です）。または、たとえば、condaはbowerのような「プロジェクトレベル」のパッケージマネージャーの適切な代替品ではない可能性があります。

また、condaを/パッケージマネージャーとして明示的に使用するディストリビューションを構築する場合を除いて、カーネル拡張機能やカーネル自体などのシステムレベルのライブラリ（プレフィックスにインストールする必要のあるライブラリ）の管理にcondaを使用しないでください。

これらのことについて私が言う主なことは、condaパッケージは一般に再配置可能に作られているということです。つまり、パッケージのインストールプレフィックスは重要ではありません。これが、たとえば、ハードコードされたパスがインストールプロセスの一部として変更される理由です。また、condaビルドでビルドされたダイナミックライブラリのRPATH（Linuxの場合）とインストール名（OS Xの場合）は、絶対パスではなく相対パスを使用するように自動的に変更されます。

または逆に、たとえばaptとyumがcondaが提供する機能を提供できないのはなぜですか？condaはそれらのパッケージマネージャーよりも「優れている」のでしょうか、それとも単に違うのでしょうか。

ある意味ではそれはより良いです、そしてある意味ではそうではありません。システムパッケージマネージャーはシステムを認識しており、そこにはcondaに含まれないパッケージがあります（カーネルのように、おそらくcondaに含まれるべきではないパッケージもあります）。

condaの主な利点は、環境の概念です。パッケージは再配置可能になっているため、同じパッケージを複数の場所にインストールでき、基本的に無料で、すべてを完全に独立してインストールできます。

ある種のコンテナ化を使用していますか

いいえ、唯一の「コンテナ化」は、個別のインストールディレクトリを持ち、パッケージを再配置可能にすることです。

またはすべての依存関係の静的リンク、

依存関係のリンクは完全にパッケージ自体に依存します。一部のパッケージは依存関係を静的にリンクしますが、リンクしないものもあります。動的にリンクされたライブラリでは、上記のようにロードパスが変更され、再配置可能になっています。

なぜそんなに「クロスプラットフォーム」なのですか？

この場合の「クロスプラットフォーム」とは、「クロスオペレーティングシステム」を意味します。同じバイナリパッケージはOSX、Linux、Windowsで機能しませんが、要点はconda自体が3つすべてで同じように機能するため、3つのプラットフォームすべてで同じパッケージを構築している場合は、それらをすべて同じように管理できます。どちらを使用しているかに関係なく。