In preparing for a tutorial on Python eggs, I'm wrestling with the *precise* definition of a "Python egg". It appears to be a slippery term from the various documentation:
"There are several binary formats that embody eggs, but the most common is '.egg' zipfile format, because it's a convenient one for distributing projects. All of the formats support including package-specific data, project-wide metadata, C extensions, and Python code."
Ok, so what binary formats -other than- .egg files are actually eggs? I figure RPMs, .debs, etc. are eggs, as long as they have an EGG-INFO subdirectory and conform to certain basic structural rules.
"Eggs are pluggable distributions in one of the three formats currently supported by ``pkg_resources``. There are built eggs, development eggs, and egg links."
Hmmm, so it's not just binary distributions that can be eggs, but also egg-links and development eggs. The concept of a "built egg" egg still includes an RPM or .deb though.
"Python Eggs are the preferred binary distribution format for EasyInstall, because they are cross-platform (for "pure" packages), directly importable, and contain project metadata including scripts and information about the project's dependencies. They can be simply downloaded and added to sys.path directly, or they can be placed in a directory on sys.path and then automatically discovered by the egg runtime system."
Well drat, so RPMs and .debs are -not- eggs, because you don't just place them on sys.path directly to use them. Egg-links don't quite fit that definition either, unless you look at them funny. So what -other- binary format could that first paragraph be talking about that can be dropped onto sys.path and be picked up by Python?
Python eggs are so very zen; you can only understand them by already understanding them.