Re: [Distutils] formencode as .egg in Debian ??
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.
Reply to: