[Distutils] .egg in Debian summary?

[Phillip J. Eby]

At 12:17 AM 11/23/2005 -0600, Bob Tanner wrote:
>Bob Tanner wrote:
>
> >> I don't think Debian should use the egg structure. It apparently relies
> >> on building a long sys.path (even though through only a single .pth
> >> file);
> >
> > I'm not sure of how .eggs are implemented, but I'm going to cross-post
> > this info to the python-distutils mailing list.
>
>Read and re-read the complete thread regarding .eggs in Debian and I cannot
>tell if any progress has been made.
>
>Still in the discussion/fact-finding stage?
>
>As "just a package maintainer" I was looking for the "options" to move
>forward. Looking at the thread, I think these are the options (skipping the
>pro's and con's for now):
>
>1. Do nothing, go with the status quo as documented in the Debian python
>policy, which is no .egg's and unpackage everything into a sub-directory of
>site-packages.
>
>2. Investigate easydeb <http://cheeseshop.python.org/pypi/easydeb/>
>
>3. Using Phillip's .egg-info solution
><http://permalink.gmane.org/gmane.comp.python.distutils.devel/2567>
>
>Any others?

#1 is pointless if your goal is to get TurboGears packaged.  As others have 
pointed out, future versions of TurboGears will be depending even more 
heavily on egg metadata than the current version does, and many of 
TurboGears' dependencies (e.g. SQLObject) already make use of egg metadata 
themselves, even if some only need the metadata for the sake of the 
projects that use them.

#2 or something like it is the best long-term approach in my view, in that 
it supports a more automated packaging process, while avoiding 
inter-project name conflicts and properly supporting namespace 
packages.  Also, under a 'pyegg' namespace, it could also be reasonable to 
install some projects such that 'require()' is necessary to use them.  But 
there are a number of practical hurdles -- including policy decisions -- 
that keep this option from being a quick and easy choice.

Practically speaking, I think #3 is the best compromise/transitional 
option, especially for packaging things like ElementTree, which is not 
packaged using setuptools, but which other projects need egg metadata 
for.  This allows the existing Debian Python packages to be utilized by the 
egg system without duplication, since you need only add an empty .egg-info 
directory to the existing Debian packages.  (Since the only metadata needed 
is the project name and version, which can be supplied from the .egg-info 
path.)

I double-checked the implementation, and I'm going to have to actually 
change setuptools a bit to support this, because currently it doesn't parse 
the version from an .egg-info directory name.  This is easy to fix, though, 
and I can put it out in 0.6a9, along with a 
--single-version-externally-managed option for the easy_install and install 
commands, and perhaps a bdist_rpm command using the same approach.  These 
changes shouldn't take long, though.  Until then, however, you would have 
to create an .egg-info/PKG-INFO file to be compatible with 
currently-released versions of setuptools.