[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Distutils] formencode as .egg in Debian ??



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  /  ianb@colorstudy.com  /  http://blog.ianbicking.org



Reply to: