[Distutils] formencode as .egg in Debian ??

Ian Bicking ianb at colorstudy.com
Tue Nov 22 21:00:01 CET 2005


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


More information about the Distutils-SIG mailing list