Phillip J. Eby wrote:
It would be, if .eggs were a packaging format, rather than a binary distribution/runtime format.
Remember "eggs are to Python as jars are to Java" -- a Java .jar doesn't contain documentation either, unless it's needed at runtime. Same for configuration files.
But there's generally no need to easily have a look into a .class file with a tool the user is used to whereas for python, we're often interested in knowing the details. And having a zip file in my way to the source has left me frustrated often enough. If you want to be consequent and consistent leave out the .py files from eggs, a jar file normally doesn't contain .java sources files either.
They're not system packages, in other words. The assumption that they are is another marketing failure, due to conflation of "package == distribution of python code" and "package == thing you manage with a system packager". People see, "I put my package in an .egg" and think it's the latter definition, when it's barely even the former. :)
I agree that they are not system packages, but I would have prefered to install multiple versions of a package to separate "site-packages" directories, something that is really well understood by most unsofisticated python programmers. The selection of the version could then be made at runtime by a PYTHONPATH setting and not by fiddling with .pth files (something that could be autmated by a tool and persisted in batch files).