Seeking the Essence of the Concept of an Egg
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? -Jeff Python eggs are so very zen; you can only understand them by already understanding them.
I think that the confusion comes from the blurring of eggs and setuptools. IMO, when most people use the term "egg", they are really referring to the packaging system provided by setuptools and easy_install (and the other applications, like buildout) that build on setuptools). IMO, the actual distribution format isn't that important. Source distributions have advantages over eggs for distribution in many cases, but what's really important is setuptools. Jim On Feb 28, 2008, at 5:46 AM, Jeff Rush wrote:
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?
-Jeff
Python eggs are so very zen; you can only understand them by already understanding them. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Jim Fulton Zope Corporation
At 04:46 AM 2/28/2008 -0600, Jeff Rush wrote:
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.
No - they're not. They *contain* eggs, they aren't eggs themselves.
"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.
Development eggs are .egg-info eggs. This definition *is* a bit slippery though, in that an egg link isn't "really" an egg, except in the sense that a symlink to a directory is a directory. :) If you want a solid definition, I'd say that built eggs (.egg file or directory) and development eggs (.egg-info eggs) are the only "real" eggs, as they are directly importable (as described below).
"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?
There isn't one now - it was phrased that way to leave open future possibilities.
participants (3)
-
Jeff Rush
-
Jim Fulton
-
Phillip J. Eby