I explain this a lot in my SciPy 2014 conversations. Let me give you a little sketch here.
Firstly, the conda package is really simple. These are just tarball files that need to be installed along with some metadata in the info directory. For example, the conda package for python is a file archive
info/ files index.json ... bin/ python ... lib/ libpython.so python2.7/ ... ... ...
You can see exactly how it looks by looking at the extracted packages in the Anaconda pkgs . The full specification is at http://conda.pydata.org/docs/spec.html .
When conda installs this, it extracts the tarball into the pkgs directory and hard links the files into the installation environment. Finally, some files that have some hard-coded installation paths are replaced (usually these are shebang strings).
This is basically it. There is something else that happens in terms of resolving dependencies, but as soon as he knows what packages he is going to install, how he does it.
The process of creating a package is a bit more complicated. @mattexx's answer and the document that it links describes a bit of the canonical way to build a package using the conda assembly.
To answer other questions:
Also, since it is python agnostic and seems to work so well and smoothly, why isn't it used as a general-purpose package manager like apt or yum?
Of course you can. The only thing that limits this is the set of packages that were created for conda. On Windows, this is a very good option, since there are no system package managers like Linux.
What are the limitations of using only conda as a package manager? Will this work?
This will work if you have conda packages for everything that interests you. The main limitation is that conda only wants to install things in the conda environment, so anything that requires specific installation locations on the system may not be very suitable for conda (although it is still possible if you set this location as the path medium). Or, for example, conda may not be a suitable replacement for project-level package managers, such as a gazebo.
In addition, conda should probably not be used to manage system-level libraries (libraries that must be installed in the / prefix), such as kernel extensions or the kernel itself, unless you intend to create a distribution that uses conda as a package manager explicitly .
The main thing I'm saying is that conda packages are usually rearranged, which means that the package installation prefix doesn't matter. This is why hard-coded paths change, for example, as part of the installation process. This also means that dynamic libraries built using the conda assembly will have their own RPATH (on Linux), and installation names (on OS X) will automatically change to use relative paths instead of absolute ones.
Or vice versa, why? can't apt and yum provide conda functionality? Is Konda better than a package manager or just another?
In a way, it’s better, but in a way it’s not. Your system package manager knows your system, and there are packages that won't be in the cond (and some, like the kernel, probably shouldn't be in the cond).
The main advantage of conda is the concept of the environment. Since packages can be moved, you can install the same package in several places and effectively have completely independent installations of everything, mostly for free.
Does he use some kind of container packaging
No, the only "containerization" has separate installation directories and does the movement of packages.
or static linking of all dependencies,
Dependency binding is completely dependent on the package itself. Some packages statically link their dependencies, some do not. Dynamically linked libraries have their own loading paths, as I described above, to be roaming.
why is it so cross-platform?
"Cross-platform" in this case means "cross-operating system." Although the same binary package cannot work on OS X, Linux, and Windows, the fact is that the conda itself works the same on all three, so if you have the same packages created for all three platforms, you can manage them anyway no matter where you are on.