M.-A. Lemburg wrote:
Eggs give room for package metadata that doesn't exist otherwise.
Putting dependencies aside, this is functionality that simply doesn't
exist with the standard distutils installation. In the case of
FormEncode, it doesn't make use of any egg features (except that other
packages may want to depend on it using setuptools). In the case of
other frameworks -- including TurboGears (which I think is the ultimate
packaging goal here) -- the Egg metadata really is important, it's not
just used for dependencies.
Understood, but wouldn't it be reasonably possible to
also install this meta-data into a standard site-packages
package directory ?
An egg and Python packages don't map 1-to-1. An egg can contain
multiple packages (which is fairly uncommon so far), but also a
top-level package can exist in more than one egg (i.e., namespace
packages, like zope.interfaces or paste.script). The metadata belongs
to the egg, not to the package inside the egg.
Also, some of the metadata is encoded in the directory name itself, like
the version information. I think this makes it easier to do some
scanning operations, without a single database of installed packages
(and also respecting sys.path manipulation).
That said, I think it would be nice if the transition was smoother.
E.g., if a file "ElementTree-1.2.6.egg-provided" could point to an
installed elementtree library (similar to the currently-supported
.egg-link file, but also slightly different). And, perhaps,
elementtree/ElementTree.egg-info could exist (with the same data as the
current ElementTree-1.2.6/EGG-INFO), though I think the simpler case
where extra metadata is disallowed would be easier. That would only
work for situations when there's a 1-to-1 mapping from packages to
eggs/projects, but that covers many situations, especially cases where
we're currently seeing conflicts. You lose the ability to easily
support multiple versions of a package with this, though that could
probably be handled too.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
