[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

At 02:00 PM 11/22/2005 -0600, Ian Bicking wrote:
>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.

In addition, an egg can contain various Python modules, and still have 
metadata even if no packages are involved.


>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.

It's not necessary to create a new way to do this; you can simply create 
'ElementTree.egg-info' in site-packages and put the PKG-INFO file in there 
(and any other egg-info files), and it's supported by the existing 
mechanisms just fine, as long as the project has no top-level resources 
(files, data directories, etc.), and does not participate in namespace 
packages.

So, for practical purposes, this would be more of a way to upgrade legacy 
packages to be detectable by egg-based packages, than a way to install egg 
packages as non-eggs.  However, it might be a workable compromise for 
getting many of the Debian-packaged TurboGears dependencies to be usable 
while still mostly conforming to the existing Debian policy.

A few months ago, this approach wouldn't have worked due to possible 
conflicts with locally-installed eggs, but setuptools now has runtime 
conflict management that can smooth it over as long as you haven't imported 
any of the conflicting packages yet.


>   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.

This approach won't support multiple simultaneous versions, but then 
neither do most system packaging tools, and if this is strictly a 
workaround for system packagers who don't want to move everything to eggs, 
then it works just fine for that.  They will, however, have to be careful 
about namespace packages in setuptools-based packages, since the package 
directories will be shared by two separately-installed projects, and each 
package will want to include its own __init__.py files.